[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] 2PC or 3PC
An
interesting piece of work in this area is Lamport/Gray Paxos Commit. Subject to patent, as I understand it. Alastair -----Original Message----- Hi all, Sorry for my long
absence, but now I am finally trying to get involved again into CAF. Since it is time to start
thinking about the CF specs (next step after Context), I was trying to imagine
possible practical cases of other protocols for coordination besides 2-phase
commit. Hence the question I
would like to discuss: what is the view of this community on the applicability
of 3-phase commit (3PC) in SOA architectures? 3PC is generally believed
to be better than 2-phase because of its non-blocking character in some
situations. It's also mentioned in the initial CF draft text. But, if I recall
correctly, there is a theorem (Nancy Lynch, MIT) which states that distributed
agreement is not possible in systems where both nodes and communication can
fail and/or time out. The net practical result
is that 3PC can also block (like 2PC) in realistic environments like IIOP, HTTP
or any other transport protocol I know. Due to this, and the
increased message overhead (3 rounds instead of 2), it seems unlikely to me
that this protocol will get significant acceptance in an SOA world. 2PC is
simpler and probably just about as good in practice. I am not saying that 2PC
is the only protocol (and that's also not the kind of thread I wanted to
start). Instead, I just want to validate my view on 3PC applicability for web
services here. I know about the WS-R work going on, but it seems unlikely that
this will offer deterministic time limits for message delivery (correct me if I
am wrong?). As a result, WS-R falls under the above theorem and will not
improve 3PC performance either. Any thoughts/comments/ideas?
Thanks, Guy Dr. Guy Pardon (
guy@atomikos.com ) Atomikos: Your Partner for
Reliable eBusiness Coordination http://www.atomikos.com/ The information in this
email is confidential and only meant for the addressee(s). The content of this
email is informal and will not be legally binding for Atomikos. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]