Re: PATCH: two phase commit

James Henstridge wrote:

> I don't think it'd be a total loss if the API didn't cover the case of
> a watchdog script in the first iteration (provided we don't cut off
> the possibility of adding support).

Sure, but your original patch exposed all possible functionality.

> In which situations do you see the connection getting closed other
> than the application crashing?  If the application is also acting as
> the transaction manager (as the case would be with Zope apps), then it
> will also have died.

During two phase commit, you have 2+ data stores. Any of them could raise an
exception during commit. If, say, the third data store fails to commit you
have a problem because the first two have committed and most likely cannot
be rolled back.

If, at this point, you roll back the 4th+ data stores you now have
inconsistent data in the first two. An admin now has to come along and
manually repair the data in the 1st, 2nd and possibly 3rd data stores.

If your app just says 'whoops' and doesn't try to get smart and roll things
back, you have more options. In many environments you can even automate the
recovery by having your watchdog commit the dropped prepared transactions.

-- 
Stuart Bishop <[email protected]>
http://www.stuartbishop.net/

_______________________________________________
Psycopg mailing list
Psycopg-IAPFreCvJWPBWskQ1e/[email protected]
http://lists.initd.org/mailman/listinfo/psycopg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHlHuyAfqZj7rGN0oRAmIdAJwIgKzgKfA9n1tZKo6IR0RTz2CblQCeIMA7
aK6fxJKM8lR/BrUdjyRu34A=
=AvI+
-----END PGP SIGNATURE-----