Re: PostgreSQL XAResource & GlassFish 3.1.2.2

From: Bryan Varner <bvarner(at)polarislabs(dot)com>
To: Florent Guillaume <fg(at)nuxeo(dot)com>
Cc: Kevin Grittner <kgrittn(at)ymail(dot)com>, 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-14 16:29:06
Message-ID: 511D10D2.2040202@polarislabs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On 02/14/2013 09:59 AM, Florent Guillaume wrote:
> 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.

Yep, it sure does.

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

As I've been thinking about this, in theory unless all the physical
connections are consumed servicing an XID and have been suspended by the
TM, at some indeterminate point in time, at least -one- of them will
have an end() invoked, and become available for use to service the
XAResource invocation.

Only if all the connections created by the datasource are in a suspended
TX would there be a potential for a 'deadlock' needing an extra control
connection -- and even then, that would be an extreme corner-case -- one
that I'd like would recover at some point with a TM-driven TX timeout,
or the TM deciding to resume a suspended TX.

I know this would play out in a case where there's a lot of REQUIRES_NEW
branching going on, but I haven't quite nailed down (mentally) a case
where this could occur without the TM exhausting a pool (if it's even
using one).

Regards,
-Bryan Varner

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Thor Michael Støre 2013-02-14 16:43:53 Finding exact column type via java.sql.ResultSetMetaData
Previous Message rhaman 2013-02-14 16:26:37 Re: PostgreSQL XAResource & GlassFish 3.1.2.2