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=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=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<mailto: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

Reply via email to