On 26 Nov 2010, at 18:58, Vladimir Blagojevic wrote:
Hey,
On 10-11-26 12:15 PM, Manik Surtani wrote:
>
>> I like option 1 as well. I am interested in details of how this can be done. How
do we set lock acquisition timeout for InvalidateL1Command, issue command to abort
specific tx etc etc?
> Propose a design, we can review it here.
>
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?
Also what would this look like in the case of a Leave? Rehashes + L1 invalidations would
happen 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.
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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org