Ah I didn't realize that PG could issue a COMMIT PREPARED from a
different connection than the one that issued the PREPARE TRANSACTION
but thinking about it it's logical.
So I believe that the setup you propose (having one additional control
connection) could be useful. You could probably avoid using it (and
therefore synchronizing work) if the physical connection is not
already reassociated to another XID.
Florent
On Wed, Feb 13, 2013 at 11:20 PM, Bryan Varner <bvarner@polarislabs.com> wrote:
>>> 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
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
