Re: PostgreSQL XAResource & GlassFish 3.1.2.2

Поиск
Список
Период
Сортировка
От Bryan Varner
Тема Re: PostgreSQL XAResource & GlassFish 3.1.2.2
Дата
Msg-id 511D10D2.2040202@polarislabs.com
обсуждение исходный текст
Ответ на Re: PostgreSQL XAResource & GlassFish 3.1.2.2  (Florent Guillaume <fg@nuxeo.com>)
Список 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


В списке pgsql-jdbc по дате отправления:

Предыдущее
От: rhaman
Дата:
Сообщение: Re: PostgreSQL XAResource & GlassFish 3.1.2.2
Следующее
От: Thor Michael Støre
Дата:
Сообщение: Finding exact column type via java.sql.ResultSetMetaData