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

Re: Postgres XA support

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Ludovic Orban <lorban(at)bitronix(dot)be>
Cc: Kris Jurka <books(at)ejurka(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Postgres XA support
Date: 2006-10-31 13:22:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Ludovic Orban wrote:
> Kris,
> 2006/10/30, Kris Jurka <books(at)ejurka(dot)com>:
>> I see how Allan's patch would get UPDATE 1 to commit, but UPDATE 2 and 3
>> are the equivalent of an interleaved transaction and I don't see how that
>> could possibly work.  I'm not sure what sort of protection we need to add
>> to prevent people from doing this or other transaction handling 
>> actions on
>> the connection.  Right now the Connection object doesn't know if it is
>> being used by a XADatasource.
> The problem is not if a connection was created by an XADatasource or
> not but if it is being used in a global transaction context or not.


> Weblogic's connection pool has a parameter called
> local-transaction-supported which when set to false will disallow
> local transactions to be executed on connections taken from that pool.

The WebLogic manual isn't very helpful, this is all I found regarding 
that parameter:

"local-transaction-supported — Optional. Boolean. Set the 
local-transaction-supported to true if the XA driver supports SQL with 
no global transaction; otherwise, set it to false. The default value is 

It doesn't actually say what difference it makes or why you would want 
to set it to true. I don't see how a transaction manager could generally 
make use of the feature, because it doesn't know if a transaction is 
distributed or not until it's committed or the second resource is enlisted.

> I guess you could enforce the same behavior in the driver by throwing
> a SQLException when some query is executed and XAResource.start() has
> not been called yet or XAResource.end() has already been called.

That seems like the easiest solution. We'll have to wrap the Connection 
object returned by PGXAConnection.getConnection so we can intercept 
execute-calls, though.

   Heikki Linnakangas

In response to


pgsql-jdbc by date

Next:From: Strong, DavidDate: 2006-10-31 15:47:58
Subject: Re: jdbc driver performance TODO
Previous:From: Dave CramerDate: 2006-10-31 12:20:25
Subject: Re: confused about transactions and connection pools

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