Jörn Gersdorf created ARIES-1246:
------------------------------------

             Summary: ConnectionManagerFactory does not honor aries.xa.name 
service property
                 Key: ARIES-1246
                 URL: https://issues.apache.org/jira/browse/ARIES-1246
             Project: Aries
          Issue Type: Bug
          Components: Transaction
    Affects Versions: 1.0.1-SNAPSHOT
         Environment: JBoss Fuse 6.1, aries-transaction/1.0.1-redhat-610379, 
geronimo-connector/3.0
            Reporter: Jörn Gersdorf


I´m running JBoss Fuse 6.1 (which includes 
org.apache.aries.transaction.jdbc/1.0.1-redhat-610379 as well as 
geronimo-connector/3.0).

When using XA auto-enlisting it seems that 
{{org.apache.aries.transaction.jdbc.internal.ConnectionManagerFactory}} does 
not use the service property {{aries.xa.name}} as a name; instead it uses 
{{getClass().getName()}}:

{noformat}
        if (connectionManager == null) {
            // Instantiate the Geronimo Connection Manager
            connectionManager = new GenericConnectionManager(
                    transactionSupport,
                    poolingSupport,
                    subjectSource,
                    connectionTracker,
                    transactionManager,
                    managedConnectionFactory,
                    getClass().getName(), // <-- this may be wrong
                    getClass().getClassLoader());
{noformat}

This leads to problems in 
{{org.apache.geronimo.transaction.manager.RollbackTask}} when looking up the 
{{NamedXAResourceFactory}} in case of {{XAException.XAER_RMFAIL}}:

{noformat}
                    } else if (e.errorCode == XAException.XAER_RMFAIL || 
e.errorCode == XAException.XAER_RMERR) {
                        //refresh the xa resource from the 
NamedXAResourceFactory
                        if (manager.getCommitter() instanceof NamedXAResource) {
                            String xaResourceName = manager.getResourceName(); 
// <-- this will resolve to aries.xa.name´s property value
                            NamedXAResourceFactory namedXAResourceFactory = 
txManager.getNamedXAResourceFactory(xaResourceName); // <-- this will be null 
since the factory has been registered under 
"org.apache.aries.transaction.jdbc.internal.ConnectionManagerFactory" 
{noformat} 

Now the problem is that {{manager.getResourceName()}} resolves to the value of 
the service property {{aries.xa.name}}, but  
{{txManager.getNamedXAResourceFactory(xaResourceName)}} will return null since 
{{ConnectionManagerFactory}} registered the {{GenericConnectionManager}} under 
its fully qualified class name 
({{org.apache.aries.transaction.jdbc.internal.ConnectionManagerFactory}}).

Result in my case is an endless loop of RollbackTasks since the 
NamedXAResourceFactory will never be found.

Relevant stack trace of registration:

{noformat}
                Daemon Thread [FelixStartLevel] (Suspended (breakpoint at line 
36 in XAResourceInsertionInterceptor))   
                        owns: AtomicBoolean  (id=205)   
                        
XAResourceInsertionInterceptor.<init>(ConnectionInterceptor, String) line: 36   
                        
XATransactions.addXAResourceInsertionInterceptor(ConnectionInterceptor, String) 
line: 61        
                        
GenericConnectionManager$InterceptorsImpl.<init>(TransactionSupport, 
PoolingSupport, SubjectSource, String, ConnectionTracker, TransactionManager, 
ManagedConnectionFactory, ClassLoader) line: 129     
                        GenericConnectionManager.<init>(TransactionSupport, 
PoolingSupport, SubjectSource, ConnectionTracker, 
RecoverableTransactionManager, ManagedConnectionFactory, String, ClassLoader) 
line: 67    
                        
org.apache.aries.transaction.jdbc.internal.ConnectionManagerFactory.init() 
line: 140    
                        
org.apache.aries.transaction.jdbc.internal.ManagedDataSourceFactory.register() 
line: 116        
                        Activator.addingService(ServiceReference) line: 95      
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to