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!
--
Jason T. Greene
JBoss, a division of Red Hat