Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Well, if the transaction has been rolled back, it's clearly not in
> prepared state anymore, so XAER_RMERR seems appropriate and the TM
> shouldn't get upset about that. However, the situation is more
> ambiguous if the TM issues COMMIT PREPARED and the connection is
> broken before receiving a reply. It will retry, and if the the
> COMMIT succeeded the first time, the TM will get XAER_RMERR on the
> second call. That's more serious.
There is no reason to return an error on rollback if the transaction
is unknown. If the DBMS server does not remember the transaction the
transaction manager can assume it has already been rolled back. That
is why it is appropriate to silently ignore 42704 or rollback. The
following patch does this.
This patch fixes a failure in a testsuite from Atomikos.
>
> I believe some (all?) other databases have yet another transaction
> state to handle that. After committing a transaction, the database
> still remembers the transaction ID and the fact that it was
> successfully committed. If the TM doesn't receive a reply to commit,
> it can reconnect and check the status to see if the commit
> succeeded. The transaction is forgotten about only after the TM
> sends another 'forget' command. Maybe we need to implement that in
> PostgreSQL, too.
Yes, this is needed for heuristics. That is, if a transaction manager
goes down and a system administrator commits the transaction before it
comes up again the server should not report `Undefined Object' but an
error on the lines of `Transaction Already Committed.' This is a
feature for the server and there is nothing[*] in the JDBC driver we
can do to implement this.
[*] Nothing is a strong word, it is always possible to implement a way
to store the Xids in a table. The driver should not do that without
some sort of confirmation from the application though.
--
Johann Oskarsson http://www.2ndquadrant.com/ |[]
PostgreSQL Development, 24x7 Support, Training and Services --+--
|
Blog: http://my.opera.com/myrkraverk/blog/
