Skip site navigation (1) Skip section navigation (2)

Re: Possible oversight in org.postgresql.xa.PGXAConnection.commitPrepared(Xid xid)

From: Radosław Smogura <rsmogura(at)softperience(dot)eu>
To: pgsql-jdbc(at)postgresql(dot)org
Cc: "Johann 'Myrkraverk' Oskarsson" <johann(at)2ndquadrant(dot)com>
Subject: Re: Possible oversight in org.postgresql.xa.PGXAConnection.commitPrepared(Xid xid)
Date: 2011-07-05 06:12:59
Message-ID: 201107050812.59178.rsmogura@softperience.eu (view raw or flat)
Thread:
Lists: pgsql-jdbc
"Johann 'Myrkraverk' Oskarsson" <johann(at)2ndquadrant(dot)com> Tuesday 05 of July 
2011 00:02:38
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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 may be wrong, but may VACUUM remove transactions statuses? What will happen 
in this situation if transaction will be prepared, commited or rolledback?

Regards,
Radek

In response to

Responses

pgsql-jdbc by date

Next:From: Maciek SakrejdaDate: 2011-07-05 06:41:46
Subject: Re: Question about passing array of a complex type from jdbc to plpgsql
Previous:From: Johann 'Myrkraverk' OskarssonDate: 2011-07-04 22:02:38
Subject: Re: Possible oversight in org.postgresql.xa.PGXAConnection.commitPrepared(Xid xid)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group