Re: a simple example of XA (not working)

Kris Jurka wrote:
>
>
> On Sun, 17 Jun 2007, Heikki Linnakangas wrote:
>
>> getConnection sets autocommit to false, so even though start set it to
>> true, it's reset to false in the call to getConnection. Attached patch
>> fixes that by explicitly setting autocommit to the right mode in
>> PGXAConnection.getConnection.
>>
>
> I don't think this fixes the problem completely if you have code that
> calls XAConnection.getConnection more than once:
>
> PGXADataSource xads = new PGXADataSource();
> XAConnection xaconn = xads.getXAConnection();
> XAResource xares = xaconn.getXAResource();
>
> xares.start(xid, XAResource.TMNOFLAGS);
>
> Connection conn1 = xaconn.getConnection();
> conn1.createStatement().executeUpdate(...);
>
> Connection conn2 = xaconn.getConnection();
>
> The second call to get connection will result in:
>
> setAutoCommit(true);
> setAutoCommit(false);
>
> on the real underlying connection, which will end up committing that
> part of the transaction.

You got me at first, but actually the second getConnection call will
*roll back* the first part of the transaction. See
AbstractJdbc23PooledConnection.getConnection. I don't think that's a
valid thing to do in the first place, though we could handle it more
gracefully. I added a note of that in the comment in
PGXAConnection.getConnection anyway.

I also added a comment block describing the three states a PGXAConection
object can be in.

There's still corner cases like the above, where the we really should
throw an error instead of getting confused. Another is that if you call
end(), and then use the connection for something else, that "else" will
become part of the transaction. And if you call
connection.commit/rollback/setAutoCommit, that will screw up the
not-yet-prepared transaction. It would be nice to catch and handle those
cases better, but that's more code.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com