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

Manik Surtani manik at jboss.org
Tue May 19 10:22:14 EDT 2009


On 19 May 2009, at 14:56, Vladimir Blagojevic wrote:

> On 5/19/09 12:00 PM, Manik Surtani wrote:
>>> 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.  :-)
>>
> How do we determine if a node

^^ You mean entry?  :-)

> was modified during some transaction? I am asking because the entry  
> I lookup from IC during unlock call (and before commit) always  
> returns true for CacheEntry#isChanged, even if node was not accessed  
> during tx.

Yes, that's because the Lock command would have put it there.

> If I lookup modifications through TxInvocationContext I do get  
> correct modifications but here we are dealing with WriteCommands who  
> do not have API to access key. So I have to check if WriteCommand is  
> an instance of DataCommand....
>
> My point is - there must be a better way to check for modifications  
> that I cannot find in API :(

Yes, this is how you would have to do it - for now at least.  Hmm -  
how else could we improve this - perhaps maintain a set of keys  
modified in the transaction context, so that every time a WriteCommand  
completes within a transaction, its keys are added to this set?

Cheers
--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org







More information about the infinispan-dev mailing list