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 <[email protected]> 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
