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

[Jason T. Greene]

Jason T. Greene wrote:
> 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!
> 

In other words, when using unlock with transactions, it is either a 
no-op, or it's wrong. IMO you guys should kill it ;)

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