commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ortwin Glück (Resolved) (JIRA) <j...@apache.org>
Subject [jira] [Resolved] (DBCP-378) ManagedDataSource returns uses the same underlying DB connection across JTA tx
Date Wed, 28 Mar 2012 17:07:26 GMT

     [ https://issues.apache.org/jira/browse/DBCP-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ortwin Glück resolved DBCP-378.
-------------------------------

    Resolution: Invalid

ManagedDataSource behaves correctly. The test is wrong (it compares null with null)
                
> ManagedDataSource returns uses the same underlying DB connection across JTA tx
> ------------------------------------------------------------------------------
>
>                 Key: DBCP-378
>                 URL: https://issues.apache.org/jira/browse/DBCP-378
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: Ortwin Glück
>            Priority: Critical
>
> It seems that when more than one JTA transaction is used within the same thread (suspend/resume
transaction), the ManagedDataSource always uses the same underlying DB connection. This scenario
is common in EJB containers! If the same DB connection is used the JTA suspend/resume actions
have no effect. The JTA semantics is violated this behaviour.
> Use the following code to setup a unit test that works in your environment
> // DS setup
>             XADataSource ods = new oracle.jdbc.xa.client.OracleXADataSource();
>             ...
>             TransactionManager tm = ...
>             DataSourceXAConnectionFactory cf = new DataSourceXAConnectionFactory(tm,
ods);
>             
>             AbandonedConfig ab = new AbandonedConfig();
>             ab.setLogAbandoned(false);
>             ab.setRemoveAbandoned(true);
>             ab.setRemoveAbandonedTimeout(15*60);
>             
>             connPool = new GenericObjectPool(null);
>             
>             // registers itself on the pool
>             KeyedObjectPoolFactory stmtPool = = new StackKeyedObjectPoolFactory(5);
>             new PoolableManagedConnectionFactory(cf, connPool, stmtPool, 
>                                           null, 5, 
>                                           (Collection<String>) null, // init sql

>                                           false, // read-only 
>                                           false, // auto-commit
>                                           Connection.TRANSACTION_READ_COMMITTED,
>                                           (String) null, // catalog
>                                           ab);
>             ds = new ManagedDataSource(connPool, cf.getTransactionRegistry());
> // Unit test
>         tm.begin();
>         Connection c1 = source.getConnection();
>         Connection ic1 = ((ManagedConnection) c1).getInnermostDelegate(); 
>         c1.close();
>         
>         Transaction tx = tm.suspend();
>         tm.begin();
>         c2 = source.getConnection();
>         ic2 = ((ManagedConnection) c2).getInnermostDelegate();
>         c2.close();
>         
>         assertNotSame("Pool must NOT use identical connection across tx", ic1, ic2);
>         tm.commit();
>         tm.resume(tx);
>         tm.commit();

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message