Re: [infinispan-dev] [Cloudtm-discussion] CloudTM: Additional Atomic broadcast based replication mechanism integrated in Infinispan
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(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev