Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 28 Mar 2012 17:07:26 +0000 (UTC)
From: =?utf-8?Q?Ortwin_Gl=C3=BCck_=28Resolved=29_=28JIRA=29?=
 <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <118391603.29129.1332954447873.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1082794018.28714.1332946540018.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (DBCP-378) ManagedDataSource returns uses the
 same underlying DB connection across JTA tx
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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

Ortwin Gl=C3=BCck resolved DBCP-378.
-------------------------------

    Resolution: Invalid

ManagedDataSource behaves correctly. The test is wrong (it compares null wi=
th null)
               =20
> ManagedDataSource returns uses the same underlying DB connection across J=
TA 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=C3=BCck
>            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! I=
f the same DB connection is used the JTA suspend/resume actions have no eff=
ect. The JTA semantics is violated this behaviour.
> Use the following code to setup a unit test that works in your environmen=
t
> // DS setup
>             XADataSource ods =3D new oracle.jdbc.xa.client.OracleXADataSo=
urce();
>             ...
>             TransactionManager tm =3D ...
>             DataSourceXAConnectionFactory cf =3D new DataSourceXAConnecti=
onFactory(tm, ods);
>            =20
>             AbandonedConfig ab =3D new AbandonedConfig();
>             ab.setLogAbandoned(false);
>             ab.setRemoveAbandoned(true);
>             ab.setRemoveAbandonedTimeout(15*60);
>            =20
>             connPool =3D new GenericObjectPool(null);
>            =20
>             // registers itself on the pool
>             KeyedObjectPoolFactory stmtPool =3D =3D new StackKeyedObjectP=
oolFactory(5);
>             new PoolableManagedConnectionFactory(cf, connPool, stmtPool,=
=20
>                                           null, 5,=20
>                                           (Collection<String>) null, // i=
nit sql=20
>                                           false, // read-only=20
>                                           false, // auto-commit
>                                           Connection.TRANSACTION_READ_COM=
MITTED,
>                                           (String) null, // catalog
>                                           ab);
>             ds =3D new ManagedDataSource(connPool, cf.getTransactionRegis=
try());
> // Unit test
>         tm.begin();
>         Connection c1 =3D source.getConnection();
>         Connection ic1 =3D ((ManagedConnection) c1).getInnermostDelegate(=
);=20
>         c1.close();
>        =20
>         Transaction tx =3D tm.suspend();
>         tm.begin();
>         c2 =3D source.getConnection();
>         ic2 =3D ((ManagedConnection) c2).getInnermostDelegate();
>         c2.close();
>        =20
>         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 administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira