[infinispan-dev] rehash and prepared tx

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] rehash and prepared tx

Mircea Markus
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] rehash and prepared tx

Galder Zamarreno
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] rehash and prepared tx

Galder Zamarreno
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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] rehash and prepared tx

Galder Zamarreno
Markus,

Assume that prepared tx being migrated to N3 would only happen in distributed caches? I mean, in repl or invalidation everyone would be preparing it and unless a new node was started, you could not really migrate the prepare, correct?

Now, assuming this is a distributed cache, if N3 could not acquire the locks, could you not alternatively find another node to migrate to? If any other node is available to do this, it might be better than doing what you propose. You suggestion would IMO be the last resort, if no other nodes could be found.

WDYT?

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

> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev