[LinuxFailSafe] Re: cdbd and fs2d_lock_node

[Padmanabhan Sreenivasan]

CDB locking does not follow normal locking 
semantics. It has optimistic concurrency controls 
for read transactions (minimizes the duration
of read-only operations blocking). So 
CDB reader will get older version of the data
if there is an update to the CDB node during
the read transaction. CDB reader will also get
an error and CDB reader can retry if they want.

Paddy


Kashif Shaikh wrote:
> 
> I've been looking at the cdbd's transaction system, and some bits of
> code are counter-intuitive to me.  I hope one of you or both of you can
> answer some questions I have.
> 
> In the case of fs2_write_lock, this is the lock graph (assume blocking
> locks):
> 
> NOLOCK := no lock
> READ = read lock
> WRITE := write lock
> CP := Calling/Current FS2 Process (i.e. lock is held by current
> transaction)
> DP := Different FS2 Process(i.e. lock is held by different transaction)
> NP1 := Arbitrary Node Pointer 1
> NP2 := Arbitrary Node Pointer 2
> 
> Node Lock State   | Request Lock by CP | Lock Result
> ---------------------------------------------
> NOLOCK(NP1)       | WRITE(NP1)         | OK
> WRITE (NP1) by CP | WRITE(NP2)         | OK, Lock upgrade.
> READ  (NP1) by CP | WRITE(NP1)         | FAILED.
> WRITE (NP1) by DP | WRITE(NP1)         | WAIT_FOR_LOCK(sleep)
> READ  (NP1) by DP | WRITE(NP1)         | OK!!!???
> 
> When looking at the code, the last case should block as deemed by
> fs2d_find_lock_conflict, but it doesn't in reality.  From my inspection,
> when acquiring a read lock, the transaction is not binded to the NP.
> This is a bug(I think it is)? Or has some sly unattended effect?
> 
> Now when we look at fs2_read_lock, I see some 'does not look right'
> cases:
> 
> Node Lock State   | Request Lock by CP | Lock Result
> ---------------------------------------------
> NOLOCK(NP1)       | READ(NP1)          | OK
> READ  (NP1) by CP | READ(NP2)          | OK, Lock upgrade.
> WRITE (NP1) by CP | READ(NP1)          | OK, NO-OP, Keep lock as RW
> READ  (NP1) by DP | READ(NP1)          | OK
> WRITE (NP1) by DP | READ(NP1)          | OK!!!???
> 
> The last case is critical, though according to the code, I don't see any
> lock conflict performed by current process's attempt to acquire a read
> lock on a node that has been write locked by another process.
> 
> Why is this the case? Intuitively, I would expect the process to block,
> but it doesn't! At the very least, it should fail.  Are there some
> assumptions being made, for which I'm not aware of? Or are cdbd locking
> semantics completely different from the norm?
> 
> Sorry for asking you two so many questions :)
> 
> Regards,
> 
> Kashif Shaikh

-- 
Padmanabhan Sreenivasan (Paddy) 
High Availability & Clustering 
(650) 9336331