Thread: Re: Two Phase Commit WAS: Re: Two weeks to feature freeze
Tom, "Putting in "dozens of hours" is not the issue here --- the problem is that there isn't any solution in sight, and I'm not eager to go down a path that has an obvious dead end." Well, I doubt we're breaking any new ground with this discussion. If I really cared about this feature, I would get in touch with CJ Date and see what he has to say about it; but I don't care that much, except from a "Postgres marketability" perspective. Perhaps the people on this list who are pushing 2PC could do the ground work? I'd suggest starting with the collected works of CJ Date and Hugh Darwin, and contacting them if it's not already in a book. -- -Josh BerkusAglio Database SolutionsSan Francisco
> Perhaps the people on this list who are pushing 2PC could do the ground work? - 2PC is better than a standard transaction when dealing with multiple servers as it can recover in some circumstances (but not all). - 2PC (XA support as described by the X/Open group) is the only implementation of distributed transactions supported by many third party components -- that I'm aware of -- to the point where it is a part of the Java Spec on dealing with distributed transactions. - 2PC isn't very good in a number of circumstances, as such PostgreSQL should avoid its use when PostgreSQL has a choice in the matter -- like communication with other PostgreSQL servers. This is a case of learning to speak Japanese because all of the people you want to talk with only speak Japanese. It simply doesn't matter how good Esperanto is. -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
Rod Taylor wrote: >>Perhaps the people on this list who are pushing 2PC could do the ground work? > > - 2PC is better than a standard transaction when dealing with multiple > servers as it can recover in some circumstances (but not all). > > - 2PC (XA support as described by the X/Open group) is the only > implementation of distributed transactions supported by many third party > components -- that I'm aware of -- to the point where it is a part of > the Java Spec on dealing with distributed transactions. > > - 2PC isn't very good in a number of circumstances, as such PostgreSQL > should avoid its use when PostgreSQL has a choice in the matter -- like > communication with other PostgreSQL servers. > > This is a case of learning to speak Japanese because all of the people > you want to talk with only speak Japanese. It simply doesn't matter how > good Esperanto is. I don't think it could have been said any better. There are a host of improvements on the standard 2PC protocol, including 3PC, multi-cast 2PC, and other variants both synchronous and asynchronous. But if PostgreSQL is going to work with XA, then it doesn't get to choose the TM or the protocol. The only relevance of this thread, as I see it, is whether or not core will stomach an XA-compatible 2PC implementation in the backend. If not, then is Satoshi Nagayasu in vain? That was what I "sensed" in the original thread 6 months ago, that the 2PC work being done by Satoshi Nagayasu was going to be allowed to die on the vine. Mike Mascari mascarm@mascari.com
Rod Taylor wrote: -- Start of PGP signed section. > > Perhaps the people on this list who are pushing 2PC could do the ground work? > > > - 2PC is better than a standard transaction when dealing with multiple > servers as it can recover in some circumstances (but not all). > > - 2PC (XA support as described by the X/Open group) is the only > implementation of distributed transactions supported by many third party > components -- that I'm aware of -- to the point where it is a part of > the Java Spec on dealing with distributed transactions. > > - 2PC isn't very good in a number of circumstances, as such PostgreSQL > should avoid its use when PostgreSQL has a choice in the matter -- like > communication with other PostgreSQL servers. > > This is a case of learning to speak Japanese because all of the people > you want to talk with only speak Japanese. It simply doesn't matter how > good Esperanto is. Agreed --- other db's have it, and people ask for it, so we should just do our best and document the limitations. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> I don't think it could have been said any better. There are a host of > improvements on the standard 2PC protocol, including 3PC, multi-cast > 2PC, and other variants both synchronous and asynchronous. But if > PostgreSQL is going to work with XA, then it doesn't get to choose the > TM or the protocol. The only relevance of this thread, as I see it, is I'm no expert in this area, but XA seems to be the choice for Java based Transaction Servers, so at very least the JDBC guys will want to have the ability to fake XA. > whether or not core will stomach an XA-compatible 2PC implementation > in the backend. If not, then is Satoshi Nagayasu in vain? That was No, it's not in vain to add 2PC (XA-compatible was his interest at the time) into the backend. What is debatable is whether the PostgreSQL folks will implement a replication system based on it. > what I "sensed" in the original thread 6 months ago, that the 2PC work > being done by Satoshi Nagayasu was going to be allowed to die on the vine. It is difficult work, but is no less useful than nested transactions will be. A certain segment of the user-base will be jumping up and down when they get them, myself included. -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc