Details
-
Bug
-
Resolution: Not a Bug
-
Minor
-
None
-
None
-
None
-
3
-
9223372036854775807
Description
As part of working on LU-8347, Jinshan raises some valid points I think.
Let's say we have a VBR enabled system, recovery completed, but a client failed to join that had outstanding write locks and some dirty data.
Now before this client rejoins, another client reads some data from a file that was modified (but not yet replayed) but this first client.
questions:
1. when the first client reconnect, would it be accepted (file version is not changed because there were no writes, so I think YES?)
2. when it is accepted - that means second client actually accessed stale data - this is bad, right?
3. As part of read second client also obtained some read locks on the data that client one is going to change - this is not good.
4. What happens with replayed locks from client 1 in presence of already granted conflicted write locks?
5. In fact if somebody has a write lock on a file - that does not change file version yet, right? Only writes do - so what's to prevent conflicting writes to be in flight for such files?
I am capturing this here to better understand all these scenarios before categorizing this with a priority accordingly.