[infinispan-dev] SingleJoinTest#testTransactional failure

[Vladimir Blagojevic]

On 10-11-26 4:30 PM, Manik Surtani wrote:
>> Ok, how about this:
>>
>> 1) JoinTask issues invalidateL1Command as it is now in JoinTask
>> 2) In case of TimeoutException where cause is inability to acquire lock L on key K then issue rollback for tx T
> Hmm, who issues this?  The joiner?  :/  Surely it should be the node which has the locks?

Yes, the joiner, and the joiner does not have the lock. I think we are 
not understanding each other well here. But see below....

> Also what would this look like in the case of a Leave?  Rehashes + L1 invalidations would happen there too.

Yes we need it there too.

>> 3) Repeat 1
>> 4) Loop 1-3 until success or timeout
>>
>>
>> Questions:
>>
>> 1) For step2, can we simply do commandsFactory.buildRollbackCommand(globalTx) and broadcast this message?
>> 2) In order to achieve the above we have to add globalTx as parameter to TimeoutException where globalTx is a the tx associated with T. Is there another way to rollback a user transaction from JoinTask, another mechanism perhaps?
> Perhaps InvalidateL1Command should carry a 'force' flag and if this is true, then the recipient attempts to 'force' the lock by causing the existing lock owner to roll back.


If we can do this that would be great! Why not force L1Invalidate 
immediately? Users can redo their rolled back transactions. Surely, 
invalidate L1 , a system level command has to have precedence over any 
user tx, right? Is there a mechanism in place to do this already?


>> 3) I would also move JOIN_REHASH_END end message sent to signal successful join *after* invalidation is done. Agree? Otherwise, we can have overlapping joins.
> Well, the worst case here is that you invalidate something>  once.  No big loss.  I'd rather have the join complete sooner.
>
> Cheers
> Manik
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>