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 по дате отправления: