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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend