Hi Michael, Thanks for these excellent references -- will be downloading and reading them. My undersstanding of the Mobach et al. paper -- and the reason the 2PC approach was chosen was to satisfy legal constraints that they were working on. Their aim was more to ensure that legally both parties were covered, more than looking into the specifics of constraints of a distributed implementation. I am copying David Mobach and Benno Overeinder. regards Omer On Fri, Aug 24, 2007 at 10:35:50AM +0200, Michael Parkin wrote:
Toshi, Dominic,
As no-one else has replied...
On 23 Aug 2007, at 15:30, Toshiyuki Nakata wrote:
So, yes, there are problems but it looks like a lot of people want to have this extra commit message. Are there any written records on the pros and cons of having the 2PC?
I think this info. is very important.
A 2PC-type protocol works well when you control everything. However, where autonomous services are involved in (possibly) different administrative domains (such as in a business environment) the cons of using the 2PC style in agreements like this are well understood, for example:
* Skeen's paper [1] on commit protocols describes why 2PC is a blocking protocol.
* Pat Helland (formally Amazon, now Microsoft) describes the 2PC protocol as the "anti-availability protocol" [2] because of the fact it can block the transaction manager (Dominic, this would be the AR in your protocol). As he says: "[2pc] is best used sparingly".
(Toshi - I also direct you to his article on "accountants don't use erasers" [3] about why agreements should not be overwritten).
* Mark McKeown also has a blog article [4] about the difficulty of distributed consensus, which is essentially what you're trying to achieve (FTA: "consensus was originally called agreement").
* If you want a lighter read the Wikipedia article [5] also discusses 2PC's blocking.
About the Mobach, et. al. paper [6] - the last three steps in Figure 2.4 are a 2PC-type protocol. When the 'DC' (from the paper) returns the 'agreement offer' to 'A' they are blocked from offering those resources to anyone else (although this is an assumption because the paper doesn't say explicitly what the 'agreement offer' actually means).
Imagine the scenario: DC returns an offer to A1 saying 'these resources for €10". Meanwhile A2, who is prepared to pay €10,000 for the same resources cannot make the agreement because DC has offered them to A1. A2 then goes and makes an agreement with another DC (e.g. another business) and A1 decides they don't want the resources and return a reject message. DC has lost €10,000 of income it could have made because of the protocol it is using.
If A1 is a proxy for a competitor of DC it could repeatedly keep asking for offers it never intends to agree to meaning DC may loose revenue...
Dominic: before I comment further on your proposed protocol what semantics are you attaching to the 'offer' message that the AR returns to the AI? Does the offer mean 'if you accept I will guarantee providing what is contained in this offer' or does it mean something else?
Michael.
[1] http://www.cs.cornell.edu/courses/cs614/2004sp/papers/Ske81.pdf [2] http://blogs.msdn.com/pathelland/archive/2007/05/20/soa-and- newton-s-universe.aspx [3] http://blogs.msdn.com/pathelland/archive/2007/06/14/accountants- don-t-use-erasers.aspx [4] http://betathoughts.blogspot.com/2007/06/brief-history-of- consensus-2pc-and.html [5] http://en.wikipedia.org/wiki/Two-phase_commit [6] www.iids.org/publications/scpe06.pdf
-- graap-wg mailing list graap-wg@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg
-- http://www.cs.cf.ac.uk/User/O.F.Rana/index.html / work-fax:+44(0)29-2087-4598 work:+44(0)29-2087-5542 / other:+44(0)7956-299981 / distributed collaborative computing / room n2.14 / school of computer science / cardiff university queen's buildings / newport road / cardiff cf24 3aa / wales / uk