[infinispan-dev] First working version of lock/unlock API

Vladimir Blagojevic vblagoje at redhat.com
Tue May 19 03:33:22 EDT 2009


On 5/13/09 4:12 PM, Manik Surtani wrote:
> By way of tests you want to make sure:
>
> 1.  Concurrent non-tx writes on the same node are held back by the lock
> 2.  Concurrent non-tx writes on a different node are held back by the 
> lock
> 3.  As 1 but with concurrent tx writes
> 4.  As 2 but with concurrent tx writes
> 5.  Test that locks are released on commit even if there is no 
> explicit unlock()
> 6.  As 5 but with rollback
> 7.  Test that locks are released on unlock if the key is not modified 
> in the tx
> 8.  Test that locks are NOT released despite unlock if the key is 
> modified in the tx.  Should only unlock on commit/rollback in this case.
>
I finished all tests except 8. I am confused with implied semantic of 
unlock. What is the point of having unlock then? If we are allowing 
locking with transactions only why do we need unlock?



More information about the infinispan-dev mailing list