---------- Original Message -----------
From: "Ann W. Harrison" <aharrison@...>

> That kind of breaks transactions ... the remote transaction is
> committed while the local transaction is still running...
> Ann

------- End of Original Message -------

Indeed. It would be meant as a temporary solution anyway, and on top of that, it
seems most DBMS's can't agree on distributed transactions and transaction
managers (everyone seems to have their own XA TM, they don't play well with each
other...) So I figured that was out of reach no matter what.

I was thinking about the lack of "finally" clause in PSQL though -- by having the
UDF's track the relationship between current_transaction and the various handles
(you provide the first link, then it tracks them as you chain them together,) a
couple of global transaction triggers (ON COMMIT, ON ROLLBACK) could fix any
handle leaks caused by an exception thrown in the stored procedure(s) by always
calling something like:

odbc_cleanup (current_transaction);

I suppose they *could* also commit and rollback any currently-open transactions
started inside of current_transaction, but ew? Transaction triggers are
effectively called during the "prepare" part of 2PC, right? So if these failed to
commit a remote transaction there, the local one could be prevented from
committing as well, and a commit re-attempted? But if it succeeds, and there's
some later failure locally (multiple on-commit triggers, and this one isn't last)
there's still an opportunity for unsynchronized commit, without any crashes even
being involved.

So yeah, I consider that out of [my] scope.

-Philip