[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