Atomikos Forum

Hello,
We've been experiencing a behaviour with the atomikos connection pool management (com.atomikos.jdbc.nonxa.AtomikosNonXADataSourceBean).
The behaviour can be detailed as follows:
- Let's suppose that the connection pool contains only one connection for simplifying the case
- The application is using Hibernate for any access to database
- The connection release mode on hibernate is configured to "after_statement" (recommended configuration by Hibnerate)
- A first process P1 gets the connection and executes a statement but doesn't close the transaction (the transaction have more operations to do). The connection is then returned to the pool as the statement is done.
- A second process P2 tries to get the connection, but the connection is marked as in use in the pool as the transaction is still on going (heuristic management). P2 waits on the connection
- P1 requests again the connection and although P1 is allowed to use connection it waits on the synchronized method getConnection()
- P2 ends with a timeout and P1 gets the connection and continues the process.

The unwanted behavior is that P1 have to wait and queue behind P2 knowing that P1 is allowed to get the connection.
What can be enhanced is that the wait for the timeout for P2 is done outside the synchronized method so that any other thread that is allowed to get the connection can do it without having to wait.

Is it possible to check this case?

Thanks in advance.

Regards,
Jed

I think this is one of the better things that will be part of the 3.9 release. To be sure we got it right: what version are you talking about, so I can check if we did change this with respect to your config?

Thanks

Hi Guy

I can confirm the issue: we have exactly the same deadlock issue that reported by Jed.

We are using Atomikos 3.7 with Hibernate 3.6.10.

We could shorten the transaction timeout but then P2 thread will not get a connection and will fail.