Re: XA support

On Thu, 30 Jun 2005, Oliver Jowett wrote:

> Heikki Linnakangas wrote:
>
>> B. When the second transaction starts, the first transaction is prepared
>> behind the scenes, freeing the connection for the new transaction.
>
> This is probably the way to go initially, since it's much simpler. It
> should also deal with the more common uses of XA where you're just
> coordinating 2 or more resources in an otherwise straightforward
> begin-do stuff-commit sequence. We can get clever later :)
>
> Related issues: supporting this case:
>
>  xaRes.start(xid1, XAResource.TMNOFLAGS);
>  stmt.executeUpdate("...");
>  xaRes.end(xid1, XAResource.TMSUSPEND);
>  // ...
>  xaRes.start(xid1, XAResource.TMRESUME);
>  stmt.executeUpdate("...");
>  xaRes.end(xid1, XAResource.TMSUCCESS);

This is essentially impossible with approach B, if the ... part uses the
connection for some other xid. Otherwise, should work.

> and this one:
>
>  xaRes.start(xid1, XAResource.TMNOFLAGS);
>  stmt.executeUpdate("...");
>  xaRes.end(xid1, XAResource.TMSUCCESS);
>  // ...
>  xaRes.start(xid1, XAResource.TMJOIN);
>  stmt.executeUpdate("...");
>  xaRes.end(xid1, XAResource.TMSUCCESS);

Practically the same as above, really.

> and this one (yow!):
>
> (thread 1):
>  xaRes.start(xid1, XAResource.TMNOFLAGS);
>  stmt.executeUpdate("...");
>
> (thread 2):
>  xaRes.start(xid1, XAResource.TMJOIN);
>  stmt.executeUpdate("...");

Note that the XA term "thread of control" actually means a connection in
JTA terms. It doesn't make any difference which java thread does work. See
JTA spec, section 3.4.3.

I'm leaning towards approach C myself, since it's the simplest to
implement and doesn't cause any unexpected prepares. Or possibly even
violating the spec and not allowing to start another transaction before
the previous one has been prepared. It depends on how the popular
application servers behave in real life.

- Heikki