Atomikos Forum

Extra JDBC connections for DataSource

Hi, I'm wondering if it is normal to have two extra DB connection created by JdbcTransactionalResource. That is, if I specify the SimpleDataSourceBean(or tomikosDataSourceBean) to have maximum of 1 connection, I'll always have 2 extra connections created (total 3 DB connections) when refreshXAConnection is called. Are these connection required to perform XA related tasks or there is something wrong with my configuration?

This is observed in both 3.2.3 and 3.3.1.

Regards,
Bluefox Send private email
Tuesday, July 08, 2008
 
 
Also, I noticed that with Atomikos 3.3.1, the new connection pool has very bad resilience when it comes to dealing with database outage. In my setup, I have the following setting:

<!-- configure an Atomikos JTA-aware datasource for reporting -->
<bean id="remoteDatasource"
    class="com.atomikos.jdbc.AtomikosDataSourceBean" init-method="init"
    destroy-method="close">
    <!-- set an arbitrary but unique name for the datasource -->
    <property name="uniqueResourceName"
        value="com.gvp.rpt.remoteDB" />
    <!-- set the underlying driver class to use, in this example case we use Oracle -->
    <property name="xaDataSourceClassName"
        value="${hibernate.remote.xaDataSourceClassName}" />
    <!-- set the driver-specific XADataSource properties (check your driver docs for more info) -->
    <property name="xaProperties"
        value="${hibernate.remote.xaDataSourceProperties}" />
    <property name="maxPoolSize" value="10" />
    <property name="testQuery" value="SELECT 1" />
</bean>

However, when database comes back up, I see more than 20 active connections being established. Moreover, these connections does not seem to work properly until
"Caused by: com.atomikos.datasource.pool.CreateConnectionException: ConnectionPool: connection pool is still empty after waiting for 30 secs" is thrown, and then more connection is being created while none of them seem to work either.
Bluefox Send private email
Wednesday, July 09, 2008
 
 
Hi,

At least one extra connection is created for recovery of XA transactions - this is normal.

Guy
Guy Pardon Send private email
Wednesday, July 09, 2008
 
 
Hi Guy,

Thanks for the reply, as for my second problem regarding excessive number of connection being created after DB outage. After consulting with the documents:
http://www.atomikos.com/Documentation/HibernateIntegration
http://www.hibernate.org/hib_docs/reference/en/html/session-configuration.html
I believe it is related to the hibernate.connection.release_mode because I'm actually using SessionFactory.openStatelessSession, by changing the realease mode from auto to after_transaction, the connection pool works as expected.

However, now I have a minor problem with this change, in my unit test, the extra DB connections doesn't seem to be closed correctly if I set the connection release mode to after_transaction. I traced to the com.atomikos.icatch.jta.UserTransactionManager and the uts variable seems to be always null, hence the DB connections are leaking for each test case. I think it is because that UserTransactionManager is not a singleton and that TransactionManagerLookup creates its own instance, while I create another instance and wire it to Spring. Since the one created by hibernate creates those connections, they are left behind and never gets removed.
Bluefox Send private email
Wednesday, July 09, 2008
 
 
I also noticed that there is always 3 instances of UserTransactionManager running, so far I've identified that one is created by hibernate, one by my spring context but I'm not sure where the third copy is coming from. Also, it seems like that when setting connection release mode to auto or after_statement, the uts is created by spring's context, which can allow the connection to be correctly shut down. However, if I set the connection release mode to after_transaction then the uts is never initialized and so the connections are left behind.
Bluefox Send private email
Thursday, July 10, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics