> It is clear to me that the mechanism should be beefed up to support
> external transactions. In many cases, the external system may not
> support transaction or may have a model that doesn't integrate
> well, but in most cases, unified transactions are straightforward
> and natural.

The question is, if this mechanism belongs to the concept
of "external procedure". In current paper version (which is not yet
published, I'm waiting for comments from Paul) procedure
is "released" right after the last result had being fetched. If we
extend external procedures with 2PC support, we have to think about
procedure lifetime.

Any proposal? Currently I have two options in my mind:

a) instantiate procedure object when needed, keep it till the end of
transaction, then call its "prepare" method, after that call
either "commit" or "rollback".

b) provide a way to plug in XAResource-like (I do not know if there's
standard C++ interface, in Java it is defined in JTA) with a
possibility to be enlisted in transaction ("begin" method with
options "new" and "resume"), de-listed from transaction ("end" method
with "suspend" option), be prepared ("prepare" method), be either
committed or rolled back ("commit" and "rollback" respectively).

Advantage of the second approach is that you can control number of
instances being used (we would need something similar to JCA
architecture), because the same "resource" can participate in
multiple transaction before it is either committed or rolled back and
you can pool them.

I feel that second choice would provide us an enterprise-level
interoperability, but I'm afraid that it is too complex to bring it
into the external procedure specification, at least on this stage.

Roman