On Tue, 10 Oct 2006, Heikki Linnakangas wrote:
> Ludovic Orban wrote:
>
>> This is a common way of using a XA connection pool that mixes both
>> local and global transactions:
>>
>> c = ds.getConnection()
>> c.executeUpdate("UPDATE 1")
>> c.setAutoCommit(false)
>> c.executeUpdate("UPDATE 2")
>> tm.begin()
>> c.executeUpdate("UPDATE 3")
>> tm.rollback()
>> c.commit()
>>
>> UPDATE 1 is done in a local transaction while in autocommit mode, it
>> is committed.
>> UPDATE 2 is done in a local transaction manually committed, it is
>> committed.
>> UPDATE 3 is done in a global transaction which is rolled back, it is
>> rolled back.
>>
>> Does PostgreSQL supports this ? If not, applications using Hibernate
>> might not work as it runs queries in local transaction mode on its own
>> during startup.
>
> Hmm, we should be supporting that, but it might not work with the current
> released version given the bug with setAutoCommit reported by Allan Saddi
> recently. We should add a test case for that...
>
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.
Kris Jurka