SEO

Hi all,

I've been testing the XA implementation and found a bug. The
PGXAConnection prepare(Xid) method may return a value of XA_OK when it
should throw an XAException instead. This can lead to an inconsistent TPC
outcome.

For example, if you attempt to insert a row which violates a uniqueness
constraint and then prepare the transaction branch, the prepare() method
returns XA_OK erroneously because the PREPARE TRANSACTION statement
executes without throwing an exception even though the transaction is not
prepared.

As a workaround, I've added a query after the PREPARE TRANSACTION query in
the prepare() method which searches the pg_prepared_xacts table for a row
with the given gid just "prepared". If it doesn't find the corresponding
row, it throws an XAException with a suitable error code (I chose
XA_RBROLLBACK).

It would be cleaner if the driver could determine the success/failure of
the PREPARE TRANSACTION statement from the query itself. For instance,
have the executeUpdate("PREPARE TRANSACTION " ....) return normally if and
only if it actually prepares a transaction. If it doesn't prepare, throw
a meaningful SQLException.

Michael

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Sun, 12 Feb 2006, Michael Allman wrote:

> Hi all,
>
> I've been testing the XA implementation and found a bug. The
> PGXAConnection prepare(Xid) method may return a value of XA_OK when it
> should throw an XAException instead. This can lead to an inconsistent TPC
> outcome.
>
> For example, if you attempt to insert a row which violates a uniqueness
> constraint and then prepare the transaction branch, the prepare() method
> returns XA_OK erroneously because the PREPARE TRANSACTION statement
> executes without throwing an exception even though the transaction is not
> prepared.

Good point.

> As a workaround, I've added a query after the PREPARE TRANSACTION query in
> the prepare() method which searches the pg_prepared_xacts table for a row
> with the given gid just "prepared". If it doesn't find the corresponding
> row, it throws an XAException with a suitable error code (I chose
> XA_RBROLLBACK).
>
> It would be cleaner if the driver could determine the success/failure of
> the PREPARE TRANSACTION statement from the query itself. For instance,
> have the executeUpdate("PREPARE TRANSACTION " ....) return normally if and
> only if it actually prepares a transaction. If it doesn't prepare, throw
> a meaningful SQLException.

We can check the command status string. PREPARE TRANSACTION should
return "PREPARE TRANSACTION" command status on success and "ROLLBACK" on
failure.

- Heikki

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq