Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

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

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group