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
