Atomikos Forum |
|
Hello,
We are using Atomikos on a critical production application and we noticed some uncommitted or rolled back transactions on timeout. Here is a description of what happens in our case : 1. a long running transaction T1 (batch) locks a table Tb 2. another interactive transaction T2 tries some update on Tb and stacks on the update statement (wait on DB) 3. When timeout occurs on T2, Atomikos transaction manager starts closing all the prepared statement of T2 but stacks on the current prepared statement (as it is being on going) 4. As soon as T1 ends, T2 is unlocked and tries to add new prepared statements to the transaction 5. Atomikos transaction manager thread is also unlocked and processes the list of prepared statements 6. Both threads enter in collision on the prepared statements list and raise a ConcurrentModificationException on the list of prepared statement. 7. Atomikos doesn't handle this exception and the rollback is not processed. The table Tb is locked until restart of the application server. We are using the Non-XA connection pool in our case. The timeout is set differently between batch processes and interactive processes (that's why T1 does is not impacted by the timeout).* Hibernate is used together with spring in this application. The code that has been identified as the root cause of this behavior is on those 2 methods: 1. AbstractConnectionProxy.forceCloseAllPendingStatements() 2. AbstractConnectionProxy.addStatement() In fact the synchronization on these methods is not done on the prepared statement list and thus the concurrency on the list is not avoided. Is it possible to help us to fix this issues by : 1. checking the concurrency implementation on Atomikos 2. providing us a way to make Atomikos interrupt the currently running statement on DB if the transaction timeout is reached? Thanks in advance for your help. |