Ludovic Orban wrote:
> Kris,
>
> 2006/10/30, Kris Jurka <books@ejurka.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.
Agreed.
> 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
false."
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
EnterpriseDB http://www.enterprisedb.com