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

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: 2005-06-30 18:37:16
Message-ID: Pine.OSF.4.61.0506302116360.45052@kosh.hut.fi (view raw or flat)
Thread:
Lists: pgsql-jdbc
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

In response to

Responses

pgsql-jdbc by date

Next:From: Dave CramerDate: 2005-06-30 19:08:01
Subject: Re: XA support
Previous:From: Heikki LinnakangasDate: 2005-06-30 18:15:54
Subject: Re: XA support

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group