[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