[infinispan-dev] SingleJoinTest#testTransactional failure

Manik Surtani manik at jboss.org
Wed Dec 1 11:07:12 EST 2010


On 1 Dec 2010, at 14:56, Vladimir Blagojevic wrote:

> On 10-12-01 8:24 AM, Manik Surtani wrote:
>> Of course, but you can't expect *every* transaction to *always* remove entries it touches from L1.  This completely defeats the purpose of L1.
>> 
>> The transaction needs to be made aware that some of the keys it touched has been exposed to rehashing and hence should be removed from L1 when the tx completes.  I don't think this is hard to do: what we'd need is:
>> 
>> * A subclass of the TxInvocationContext (DistributedTxInvocationContext?) which maintains a set of keys potentially rehashed
>> * An L1InvalidationCommand would try and invalidate a key.  If it is unable to lock this key _and_ the lock is held by a transaction, add the key to the given transaction's context's potentially rehashed key set
>> * When the transaction completes, it invalidates any keys before releasing locks.
>> 
>> WDYT?
>> 
> 
> I don't know guys but although this sounds good it is a bit complicated 
> you have to admit!
> 
> I have a stupid question. Why do we allow transactions to lock keys that 
> are in L1? I mean these keys are transient on non-owner nodes so why 
> lock them to begin with?

Simpler design/impl as it is in-line with replication as well.  Happy to consider other prototype imls.

Cheers
Manik

--
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