[infinispan-dev] SingleJoinTest#testTransactional failure

[Manik Surtani]

On 9 Dec 2010, at 01:50, Vladimir Blagojevic wrote:

> On 10-12-01 1:07 PM, Manik Surtani wrote:
>> On 1 Dec 2010, at 14:56, Vladimir Blagojevic wrote:
>> 
>>> 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
>> 
> 
> Ok, I went with Manik's original proposal of trying to lock with zero 
> timeout and fail fast if unsuccessful. However, that was only half the 
> problem. The real underlying problem why SingleJinTest fails I found out 
> is sometimes prepare command prepares tx on nodes A,B and join rehash 
> actually rehashes the affected key and commit is issued on nodes say A, 
> C which of course does not commit value on B. Stale tx cleanup 
> eventually kicks in and cleans up locked key(s) on B and rolls back tx.  
> However, node B does not have expected value that tx put in and test fails.

Hmm.  Surely the commit should be broadcast to B as well?  I.e., if a tx is in fly during a rehash, commits (and rollbacks) should go to a union of the nodes on the old and new consistent hashes.

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