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

[Jason T. Greene]

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!

-- 
Jason T. Greene
JBoss, a division of Red Hat