[infinispan-dev] [Cloudtm-discussion] CloudTM: Additional Atomic broadcast based replication mechanism integrated in Infinispan

Paolo Romano romano at inesc-id.pt
Thu Apr 21 10:56:56 EDT 2011


On 4/20/11 7:25 PM, Manik Surtani wrote:
> On 20 Apr 2011, at 18:18, Paolo Romano wrote:
>
>> On 4/17/11 7:55 PM, Manik Surtani wrote:
>>> Excellent stuff, Paolo and Pedro.  My comments below, inline.  Cc'ing infinispan-dev as well.
>> Thanks Manik!
>>> On 16 Apr 2011, at 21:47, Paolo Romano wrote:
>>>
>>> ...
>>> I presume this implementation still plays nice with XA/JTA?  In that transactions marked for rollback, etc are respected?
>> Kind of :)
>>
>> We didn't really polish the code to have it fully integrated with
>> XA/JTA, but this could be done without too many problems.
>>
>> Basically, if Infinispan is the only resource in a distributed xact, and
>> it is configured to work in replicated mode, then it could externalize a
>> 1 phase commit interface. In this case, the output of the commit phase
>> would be that of the AB-based certification, avoiding totally 2PC.
>>
>> If on the other hand, Infinispan (replicated) needs to be enlisted in a
>> distributed transaction encompassing other resources, 2PC is
>> unavoidable. In this case, when an (replicated) Infinispan node receives
>> a prepare message from some external coordinator it could i) AB-cast the
>> prepare message to the other replicas, and ii) do the lock acquisition
>> and write-skew validation to determine the vote to be sent back to the
>> external coordinator. (Note that all replicas are guaranteed to
>> determine the same outcome here, given the total order guarantees of the
>> ABcast and that the certification procedure is deterministic.) The
>> write-back and lock release should instead be done upon receipt of the
>> final decision (2nd phase of the 2PC) from the coordinator.
>>
>> Does this answer your question?
> Yes.  Is there any benefit then of participating in a distributed transaction (with other resources using 2PC) while Infinispan uses AB?  We still have the network roundtrips and hold locks for the entire duration...

In general settings the benefits would be reduced... the main advantage 
would be that the replicas of Infinispan would not suffer of deadlocks 
and reply faster to the prepare messages.

This can be very effective, however, in those use cases where i) 
Infinispan is used as the only in-memory fault-tolerant transactional 
data storage, and ii) data is persisted in an asynchronous fashion 
towards some back-end storage out of the boundaries of the Infinispan's 
transaction.

Cheers

     Paolo

> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev




More information about the infinispan-dev mailing list