M.-A. Lemburg wrote: > A connection drop should always trigger an implicit rollback on the > server side, so I'm not sure how and where you'd keep the required > state to continue processing the transaction in case the connection > is reestablished.
With PostgreSQL, when you PREPARE TRANSACTION all state is flushed to disk. If your network drops before you can commit or even if your server catches fire you can still reconnect later and commit the transaction (provided your disks survive). As an example, lets say you are dealing with three data stores and an exception is raised in the second phase whilst committing the 2nd data store. If the transaction on the 3rd data store is rolled back then you can only recover by somehow rolling back the transaction on the 1st and maybe 2nd data store. Given this is probably a multi user environment this may well involve data loss. If the transaction on the 3rd data store is not rolled back, then you can recover if the problem was transient by simply retrying the outstanding commits once the network glitch or whatever has been fixed. All you need are the transaction ids you used (and why meaningful transaction ids can make your life easier at 2am). -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
