Re: 2-phase commit

> -----Original Message-----
> From: Jeroen T. Vermeulen [mailto:jtv(at)xs4all(dot)nl]
> Sent: Saturday, October 11, 2003 5:36 AM
> To: Dann Corbit
> Cc: Christopher Browne; pgsql-hackers(at)postgresql(dot)org
> 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.