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
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 |