geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Enhydra enlist/delist/enlist woes...
Date Thu, 13 Sep 2012 19:05:50 GMT
Looking a little farther into the geronimo tm code enlist method...

            TransactionBranch manager = suspendedXaResources.remove(xaRes);
            if (manager != null) {
                //we know about this one, it was suspended
                xaRes.start(manager.getBranchId(), XAResource.TMRESUME);
                activeXaResources.put(xaRes, manager);
                return true;
            }
            //it is not suspended.
            for (Iterator i = resourceManagers.iterator(); i.hasNext();) {
                manager = (TransactionBranch) i.next();
                boolean sameRM;
                //if the xares is already known, we must be resuming after a suspend.
                if (xaRes == manager.getCommitter()) {
                    throw new IllegalStateException("xaRes " + xaRes + " is a committer but
is not active or suspended");
                }


(ending with what you quoted)  note that if the xaresource had been suspended we would already
have returned true.

The "happy" sequence of calls to the tx is supposed to be like this:

tx.enlist(xares) >> xares.begin(xid, TMNOFLAGS or TMJOIN)
tx.delist(xares, TMSUSPEND) >>xares.end(xid, TMSUSPEND)

repeat as often as desired:
tx.enlist(xares) >> xares.begin(xid, TMRESUME)
tx.delist(xares, TMSUSPEND) >>  xares.end(xid, TMSUSPEND)

when you are done

tx.delist(xares, TMSUCCESS) >> xares.end(xid, TMSUCCESS)

commit.

Note the end(TMSUSPEND) immediately followed by end(TMSUCCESS).

Geronimo's connection pooling together with the tranql jdbc wrappers do it correctly, but
the released versions may not be that easy to set up in osgi by themselves.  I have a sandbox
version that is a lot more osgi friendly but haven't worked on it in a long time - not even
sure if it builds at the moment.

https://svn.apache.org/repos/asf/geronimo/sandbox/djencks/txmanager

hope this helps
david jencks


On Sep 13, 2012, at 11:30 AM, David Jencks wrote:

> Hi James,
> 
> An XAConnection is required to always use the same XAResource, so that part of their
code is good.
> 
> I think the problem is here:
> 
> 	tx.delistResource(xac.getXAResource(), XAResource.TMSUCCESS);
> 
> 
> on connection handle close.
> The TMSUCCESS flag means the next thing you're going to do on the tx is end it (commit
or rollback).  If you then try to re-enlist it that's an error (IIRC).
> 
> I think they should be using a different flag here.  Haven't had time to look into it
in detail though....
> 
> david jencks
> 
> 
> On Sep 13, 2012, at 4:41 AM, James Carman wrote:
> 
>> I am trying to use enhydra's connection pool/XA support for our
>> project.  It's a ServiceMix-based project, so we're using Aries'
>> "wrapper" around Geronimo's transaction manager.  Anyway, what I'm
>> seeing is that their XA code seems to be trying to re-enlist the same
>> connection.  Unfortunately, they re-use the same XAResource instance,
>> so I run into this bit of code causing me an error:
>> 
>> if (xaRes == manager.getCommitter()) {
>> throw new IllegalStateException("xaRes " + xaRes + " is a committer
>> but is not active or suspended");
>> }
>> 
>> Their connection code looks like this:
>> 
>> 
>> public class StandardXAConnection
>> 	extends StandardPooledConnection
>> 	implements XAConnection, XAResource, Referenceable, Runnable {
>> 
>> ...
>> 
>>       /**
>> 	 * We are required to maintain a 1-1 mapping between an XAConnection
>> 	 * and its corresponding XAResource. We achieve this by implementing
>> 	 * both interfaces in the same class.
>> 	 */
>> 	public XAResource getXAResource() {
>> 		return this;
>> 	}
>> }
>> 
>> What I'm trying to understand is if they're attempting to do something
>> silly here or if I have something mis-configured.  We're using OpenJPA
>> and when it goes to close the connection (after it uses it for a
>> query), enhydra delists it from the current transaction.  Inside their
>> DataSource's "connectionClosed" method:
>> 
>> if ((tx != null) && (((StandardXAConnection)
>> xac).connectionHandle.isReallyUsed)) {
>> try {
>> 	tx.delistResource(xac.getXAResource(), XAResource.TMSUCCESS);
>> 	// delist the xaResource
>> 	log.debug(
>> 		"StandardXAPoolDataSource:connectionClosed the resourse is delisted");
>>       } catch (Exception e) {
>> 		log.error(
>> 		"StandardXAPoolDataSource:connectionClosed Exception in connectionClosed:"
>> 		+ e);
>> 	}
>> }
>> 
>> Does this all make sense?  Is there something I need to configure to
>> allow re-enlistment of resources or are they just doing something
>> bone-headed here?
> 


Mime
View raw message