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

Mon, 13 Oct 2003 12:54:53 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: 2-phase commit
> 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.

Not really. In the event of a crash, most 2PC systems will expect the
participant to come back in the same state it crashed in.

Our nested-transaction implementation (like our standard transaction
implementation) aborts all transactions on crash.
Mon, 13 Oct 2003 20:11:08 -0400
Rod Taylor <rbt@rbt.ca>
Re: 2-phase commit
On Monday 13 October 2003 20:11, Rod Taylor wrote:
> > 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.
>
> Not really. In the event of a crash, most 2PC systems will expect the
> participant to come back in the same state it crashed in.
>

Yes, this is correct.  There are certain phases of the protocol in which the 
transaction state must be re-instated from the log file after a crash of the 
DB server.  The re-instatement must occur prior to any connections being 
accepted by the server.  Additionally, the coordinator must be fully 
recoverable as well.  The coordinator may, depending on the phase of the 
commit/abort, contact child servers after it crashes.  The requirement is 
that during log replay, the transaction structures might have to be fully 
reconstructed and remain in-place after log replay has completed, until the 
disposition of the (sub)transaction is settled by the coordinator.  All 
dependent on the phase of course.

> Our nested-transaction implementation (like our standard transaction
> implementation) aborts all transactions on crash.

Jordan Henderson


Mon, 13 Oct 2003 22:13:53 -0400
Jordan Henderson <jordan_henders@yahoo.com>
Re: 2-phase commit