> -----Original Message----- > From: Jeroen T. Vermeulen [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 11, 2003 5:36 AM > To: Dann Corbit > Cc: Christopher Browne; [EMAIL PROTECTED] > Subject: Re: [HACKERS] 2-phase commit > > > On Fri, Oct 10, 2003 at 09:37:53PM -0700, Dann Corbit wrote: > > Why not apply the effort to something already done and compatibly > > licensed? > > > > This: > > http://dog.intalio.com/ots.html > > > > Appears to be a Berkeley style licensed: > > http://dog.intalio.com/license.html > > > > Transaction monitor. > > I'd say this is complementary, not an alternative to 2PC > implementation issues.
My notion is that the specification has been created that describes how the system should operate, what the API's are, etc. I think that most of the work is involved in that area. The notion is that if you program to this spec, it will already have been well thought out and it should be standards based when completed. > The transaction monitor lives on the other side of the > problem. 2PC is needed in the database _so that_ the > transaction monitor can do its job. Theoretically, if any database in the chain supports 2PC, you could make all connected systems 2PC compliant by using the one functional system as a persistent store. But you are right. PostgreSQL still would need the "I promise to commit when you ask" method if it is to really support it. I think another way it could be handled is with nested transactions. Just have the promise phase be an inner transaction commit but have an outer transaction bracket that one for the actual commit. > That said, having a 3-tier model is probably a good idea if > distributed transaction management is what we want. :-) In real life, I think it is _always_ done this way. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster