Re: PostgreSQL XAResource & GlassFish 3.1.2.2 - Mailing list pgsql-jdbc

From Bryan Varner
Subject Re: PostgreSQL XAResource & GlassFish 3.1.2.2
Date
Msg-id 511C119E.8070409@polarislabs.com
Whole thread Raw
In response to PostgreSQL XAResource & GlassFish 3.1.2.2  (Bryan Varner <bvarner@polarislabs.com>)
Responses Re: PostgreSQL XAResource & GlassFish 3.1.2.2  (Florent Guillaume <fg@nuxeo.com>)
List 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


pgsql-jdbc by date:

Previous
From: Bryan Varner
Date:
Subject: Re: PostgreSQL XAResource & GlassFish 3.1.2.2
Next
From: Kevin Grittner
Date:
Subject: Re: PostgreSQL XAResource & GlassFish 3.1.2.2