Checking pax-jdbc, it seems you can switch to https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool-c3p0/src/main/java/org/ops4j/pax/jdbc/pool/c3p0/impl/ds/C3p0XAPooledDataSourceFactory.java
Am Di., 17. März 2020 um 09:48 Uhr schrieb Philipp Marx < smi...@googlemail.com>: > Hi Christian, > > I had the same problem. What you need to ensure is to use a ConnectionPool > which does support XAConnections / XADataSources.It is important that the > interface of the Connection Pool datasource implements XADataSource. The > only pool I have found which does support this is commons DBCP2 ( > https://commons.apache.org/proper/commons-dbcp/api-2.1.1/org/apache/commons/dbcp2/managed/BasicManagedDataSource.html). > If I didn't use one of these I could observe the exact behaviour you are > describing. Note: It doesn't matter that the physical connection from your > driver is XA enabled, since the TransactionManager usually retrieves a > "wrapped" DataSource from the pool, and if this doesn't implement the > XADataSource interface it won't be registered into the current transaction. > > Let me know if this helps. > > Cheers, > Philipp > > Am Do., 12. März 2020 um 16:11 Uhr schrieb Niehues, Christian < > christian.nieh...@its-digital.de>: > >> Hi, >> >> >> I still have problem with this setup, maybe anyone has a hint how to fix >> the transaction problem or how to use this *KeepXAConnTillTxComplete* >> property in a persistence.xml? >> >> >> Thanks in advice, >> >> Christian >> ------------------------------ >> *Von:* Niehues, Christian <christian.nieh...@its-digital.de> >> *Gesendet:* Dienstag, 23. Juli 2019 09:48:55 >> *An:* user@aries.apache.org >> *Betreff:* AW: Transaction problem in Karaf when switching from dbcp2 >> connection pool to c3p0 >> >> >> Yes I use pax-jdbc for it and I can see that the C3p0PooledDatasourceFactory >> creates the datasource. >> >> >> This is what the datasource.cfg looks like: >> >> >> *osgi.jdbc.driver.name <http://osgi.jdbc.driver.name>=oracle* >> *url=jdbc:oracle:thin:@localhost:1521:XE* >> *user=pra_user* >> *password=pra_user* >> *databaseName=PRA* >> *dataSourceName=PRA* >> *pool=c3p0* >> *xa=true* >> *c3p0.acquireRetryDelay=1000* >> *c3p0.numHelperThreads=4* >> *c3p0.maxPoolSize=25* >> *c3p0.acquireRetryAttempts=5* >> *c3p0.acquireIncrement=1* >> >> >> Only things that are irretating me is that it seems the datasource is >> created twice and that I also get some warnings: >> >> >> 2019-07-23T09:25:26,574 | INFO | FelixStartLevel | TransactionManager >> | 60 - org.ops4j.pax.jdbc.pool.common - 1.2.1 | >> TransactionManager service detected. Providing support for XA >> DataSourceFactories >> 2019-07-23T09:25:26,585 | INFO | FelixStartLevel | >> ServiceTrackerHelper | 59 - org.ops4j.pax.jdbc.config - 1.2.1 | >> Obtained service dependency: >> (&(objectClass=org.ops4j.pax.jdbc.pool.common.PooledDataSourceFactory)(pool=c3p0)(xa=true)) >> 2019-07-23T09:25:26,589 | INFO | FelixStartLevel | >> ServiceTrackerHelper | 59 - org.ops4j.pax.jdbc.config - 1.2.1 | >> Obtained service dependency: >> (&(objectClass=org.osgi.service.jdbc.DataSourceFactory)( >> osgi.jdbc.driver.name=oracle)) >> 2019-07-23T09:25:26,591 | INFO | FelixStartLevel | >> DataSourceRegistration | 59 - org.ops4j.pax.jdbc.config - 1.2.1 | >> Found DataSourceFactory. Creating DataSource PRA >> 2019-07-23T09:25:26,592 | ERROR | FelixStartLevel | >> C3p0PooledDataSourceFactory | 326 - org.ops4j.pax.jdbc.pool.c3p0 - >> 1.2.1 | Please define c3p0.dataSourceName in your configuration to prevent >> memory leaks >> 2019-07-23T09:25:26,642 | INFO | MLog-Init-Reporter | MLog >> | 198 - org.apache.servicemix.bundles.c3p0 - 0.9.5.2_1 | >> MLog clients using slf4j logging. >> 2019-07-23T09:25:26,698 | WARN | FelixStartLevel | BeansUtils >> | 198 - org.apache.servicemix.bundles.c3p0 - 0.9.5.2_1 | >> Property inaccessible for overwriting: password >> 2019-07-23T09:25:26,703 | WARN | FelixStartLevel | BeansUtils >> | 198 - org.apache.servicemix.bundles.c3p0 - 0.9.5.2_1 | >> Property inaccessible for overwriting: user >> 2019-07-23T09:25:26,707 | INFO | FelixStartLevel | C3P0Registry >> | 198 - org.apache.servicemix.bundles.c3p0 - 0.9.5.2_1 | >> Initializing c3p0-0.9.5.2 [built 08-December-2015 22:06:04 -0800; debug? >> true; trace: 10] >> 2019-07-23T09:25:26,798 | INFO | FelixStartLevel | >> ServiceTrackerHelper | 59 - org.ops4j.pax.jdbc.config - 1.2.1 | >> Obtained service dependency: >> (&(objectClass=org.ops4j.pax.jdbc.pool.common.PooledDataSourceFactory)(pool=c3p0)(xa=true)) >> 2019-07-23T09:25:26,800 | INFO | FelixStartLevel | >> ServiceTrackerHelper | 59 - org.ops4j.pax.jdbc.config - 1.2.1 | >> Obtained service dependency: >> (&(objectClass=org.osgi.service.jdbc.DataSourceFactory)( >> osgi.jdbc.driver.name=oracle)) >> 2019-07-23T09:25:26,801 | INFO | FelixStartLevel | >> DataSourceRegistration | 59 - org.ops4j.pax.jdbc.config - 1.2.1 | >> Found DataSourceFactory. Creating DataSource PRA >> 2019-07-23T09:25:26,802 | ERROR | FelixStartLevel | >> C3p0PooledDataSourceFactory | 326 - org.ops4j.pax.jdbc.pool.c3p0 - >> 1.2.1 | Please define c3p0.dataSourceName in your configuration to prevent >> memory leaks >> 2019-07-23T09:25:26,822 | WARN | FelixStartLevel | BeansUtils >> | 198 - org.apache.servicemix.bundles.c3p0 - 0.9.5.2_1 | >> Property inaccessible for overwriting: password >> 2019-07-23T09:25:26,823 | WARN | FelixStartLevel | BeansUtils >> | 198 - org.apache.servicemix.bundles.c3p0 - 0.9.5.2_1 | >> Property inaccessible for overwriting: user >> >> >> The persistenceUnit for access to the EntityManager is defined in a >> persistence.xml: >> >> *<persistence-unit name="pra" transaction-type="JTA">* >> *<provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>* >> *<jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name >> <http://osgi.jndi.service.name>=PRA)</jta-data-source>* >> *<properties>* >> *<property name="hibernate.connection.driver_class" >> value="oracle.jdbc.OracleDriver" /> * >> *<property name="hibernate.dialect" >> value="org.hibernate.dialect.Oracle10gDialect" />* >> *<property name="hibernate.archive.autodetection" value="class"/>* >> *<property name="hibernate.enable_lazy_load_no_trans" value="true"/>* >> *<property name="hibernate.connection.isolation" value="4"/>* >> *<property name="hibernate.connection.autocommit" value="false"/>* >> *</properties>* >> *</persistence-unit>* >> >> Maybe there is something wrong with that? >> I noticed some examples using *hibernate.connection.driver_class=* >> *oracle.jdbc.xa.client.OracleXADataSource* and >> *KeepXAConnTillTxComplete=true* >> but never as part of a persistence.xml >> >> >> Christian >> >> ------------------------------ >> *Von:* Christian Schneider <ch...@die-schneider.net> >> *Gesendet:* Dienstag, 23. Juli 2019 08:59:36 >> *An:* user@aries.apache.org >> *Betreff:* Re: Transaction problem in Karaf when switching from dbcp2 >> connection pool to c3p0 >> >> How do you setup the data source? You need to provide a DataSource that >> wraps a XADataSource and does auto enlistment. Do you use pax-jdbc for >> this? >> >> Christian >> >> Am Mo., 22. Juli 2019 um 15:52 Uhr schrieb Niehues, Christian < >> christian.nieh...@its-digital.de>: >> >>> Hello, >>> >>> >>> I have deployed an application in my Karaf 4.1.5 using JMS, Camel, >>> Hibernate, Aries Transaction Manager and PAX JDBC Pool. >>> >>> >>> Everything works fine except when I process parallel requests where I >>> sometimes get a SQLException from dbcp class ManagedConnection reporting >>> "Connection >>> can not be used while enlisted in another transaction" and the request >>> fails. >>> >>> After some analyses I came to the assumption that it is maybe related to >>> the fact that Hibernate doesn't support a ConnectionProvider for dbcp. >>> >>> >>> So I switch the connection pool to c3p0 which is supported by Hibernate. >>> But here I face another problem just for a single request: some DB >>> operations get executed before the transaction commits so I am also unable >>> to rollback everything on exception. It seems that all flushes initiated by >>> Hibernate directly go into the DB. >>> >>> >>> So I assume that anything with the transaction >>> synchronisation/coordination is wrong. The transactional context is defined >>> by a @Transactional annotation. From debugging I can see that the >>> AriesPlatformTransactionManager and the C3p0PooledDatasourceFactory is >>> involved. Do you have any hint what could cause this problem or how can I >>> can I do more depth analyses? >>> >>> >>> Thanks in advice, >>> >>> Christian >>> >>> >> >> -- >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Computer Scientist >> http://www.adobe.com >> >>
