Re: PostgreSQL XAResource & GlassFish 3.1.2.2

From: Bryan Varner <bvarner(at)polarislabs(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: PostgreSQL XAResource & GlassFish 3.1.2.2
Date: 2013-02-13 22:20:14
Message-ID: 511C119E.8070409@polarislabs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

>> Why would each XAConnection need it's own pool?
>
> Because one PostgreSQL connection can't interleave transactions,
> and you can't commit or roll back a prepared transaction in a
> connection which has a transaction open. I thought you wanted to
> be able to do such things. They could be done if one XAConnection
> could map to more than one PostgreSQL connection.

Assuming that each logical XAConnection is backed by exactly one
physical PGPooledConnection (and all connections are busy servicing an
XID) then the situation you've described is completely accurate, and no
different than the situation posed by the current XA implementation.

Adding one physical connection to the data source, for use by the
XAResource control signals (commit / rollback / recover / etc.) should
be sufficient to avoid a deadlock in a client app. (you'd have to be
able to queue the control statements and synchronously respond)

I don't think you need a 'pool' per XAConnection, but you may need a
number of extra physical connections in order to dispatch / handle
non-xa invocations.

Regards,
-Bryan Varner

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Ladislav DANKO 2013-02-14 08:45:55 Re: rounded brackets in prepared statement
Previous Message Kevin Grittner 2013-02-13 22:05:46 Re: PostgreSQL XAResource & GlassFish 3.1.2.2