[infinispan-dev] rehash and prepared tx

Galder Zamarreño galder at redhat.com
Thu Mar 3 03:56:30 EST 2011


Oh right, this is to with transaction recovery and http://community.jboss.org/wiki/Transactionrecoverydesign - forget what I asked.

On Mar 3, 2011, at 9:31 AM, Galder Zamarreño wrote:

> Hmmm, I'm probably missing something here, but if N2 crashes, wouldn't the tx rollback? Why should the prepare migrate to N3?
> 
> On Mar 1, 2011, at 6:54 PM, Mircea Markus wrote:
> 
>> Hi,
>> 
>> This behaviour is unspecified:
>> Tx is prepared on N1 and N2. Then N2 crashes, and prepared tx is migrated across to N3. What happens with the tx if it cannot acquire locks on N3, because there's another tx2 preparing* on N3?
>> 
>> *preparing - it cannot be finished preparing as there's already a *prepared* tx owning some of its locks. We cannot have two prepared tx that have same lock acquired.  
>> 
>> Here is my take on this scenario: if the tx is already prepared on Node1 then same tx should force lock acquisition on Node3 and force rollback of any tx that holds a lock on that node. Why? (1) because Node1's tx is already prepared and it made a commitment to the TxManager to apply state (or manual recovery needs to be done - bad for throughput and user experience. (2) on the other hand the transaction on Node3 is not yet prepared.
>> 
>> Cheers,
>> Mircea
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list