Re: XA support
- From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
- To: Oliver Jowett <oliver(at)opencloud(dot)com>
- Cc: pgsql-jdbc(at)postgresql(dot)org
- Subject: Re: XA support
- Date: Thu, 30 Jun 2005 21:37:16 +0300 (EEST)
- Message-id: <Pine.OSF.4.61.0506302116360.45052@kosh.hut.fi> <text/plain>
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
Home |
Main Index |
Thread Index