geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent Guillaume ...@nuxeo.com>
Subject Re: txmanager: shouldn't connection be removed from pool if it fails to enlist?
Date Wed, 16 Mar 2011 13:10:47 GMT
I'll try to write a patch when I find the time. In the meantime I've
made my XAResource more robust to know how to reset its state when
there's a problem.

I've tried upgrading to 3.1 but there are API changes that I can't
understand immediately how to work around:
Previously, when instantiating a GenericConnectionManager, I didn't
have to pass my ManagedConnectionFactory to it. So I could bind in
JNDI my generic ConnectionManager, later when needing a pooled
connection factory in user setup code look it up in JBDI, then do
mcf.createConnectionFactory(cm).
Now it seems I have to bind in JNDI a ConnectionManager that's tied to
a given ManagedConnectionFactory. So I have to instantiate the
ManagedConnectionFactory much earlier and in a different part of the
setup. Is that the way to go? Not sure if I'm clear :)

Florent



On Fri, Mar 11, 2011 at 9:48 PM, David Jencks <david_jencks@yahoo.com> wrote:
> Hi Florent,
>
> Thanks for finding this and figuring out what is going on!  A Jira would be great and
a patch even better!
>
> BTW you might want to switch to a newer tm as 2.2.x and 3.x have much better error handling
and recovery when a resource is not available on startup or disappears midway through a commit.
 (The changes aren't going into 2.1.x since they involve an incompatible api change).
>
> thanks
> david jencks
>
> On Mar 11, 2011, at 7:17 AM, Florent Guillaume wrote:
>
>> Hi David, all,
>>
>> I have the following situation using txmanager (2.1.3) as a standalone
>> component in my application.
>>
>> ConnectionFactory.getConnection
>> -> GenericConnectionManager.allocateConnection
>> -> TransactionEnlistingInterceptor.getConnection
>> -> TransactionImpl.enlistResource
>> -> xaRes.start
>> In my XAResource for internal reasons there's a failure to do the
>> start (no network resources available), and it throws XAException
>> XAER_RMERR.
>> So enlistResource catches this and returns false.
>> But the caller, TransactionEnlistingInterceptor.getConnection, does
>> nothing with the return code and assumes all went well. So the
>> corrupted XAResource stays in the pool and is still corrupted on the
>> next try.
>>
>> In my opinion it should return the connection to the pool with a DESTROY action.
>>
>> There's a code path catching SystemException where it does it, but
>> this exception is never raised here. I see two possible fixes:
>> 1. make TransactionImpl.enlistResource throw SystemException at least
>> when getting XAER_RMERR,
>> 2. make TransactionEnlistingInterceptor.getConnection look for a false
>> return value when calling enlistResource and in this case doing a
>> DESTROY as well.
>>
>> What do you think?
>> I can provide a JIRA ticket and a patch if needed.
>>
>> Florent
>>
>> --
>> 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
>
>



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

Mime
View raw message