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

Manik Surtani wrote: > > On 19 May 2009, at 09:41, Vladimir Blagojevic wrote: > >> On 5/19/09 9:33 AM, Vladimir Blagojevic wrote: >>>> 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? >>> >> Thought a little bit more about this. Does point 8 imply that key >> should be released on unlock if it was *not* modified and on >> commit/rollback if it was modified? > > Precisely. :-) IMO these semantics going to be badly misused. I can already see people doing: lock(k1); int count = get(k1) put(k2, count); unlock(k1); commit; // Count might have changed!