Transaction timeout in JBoss caused deadlock with spring transaction manager [SPR-8421]

[spring-projects-issues]

Sergey Astakhov opened SPR-8421 and commented

Deadlock scenario:

1. Transaction started. At some point, jdbc connection allocated from poll and registered as transaction resource.
2. After timeout event occured, JBoss try to rollback this transaction.
3. In process of rolling back transaction, reaper process try to get lock on connection to do rollback and stopped at this point in waiting.
4. Due to cancelling state of the transaction, exception is rised in main process of transaction.
5. Spring catched this exception and invokes rollback to transaction.
6. Inside jboss transaction manager there is synchronized method for making transaction abort, so this rollback invocation is waiting another thread to complete.
7. At final: JBoss hold synchronized lock on abort method, but wait for releasing lock on connection. Main process hold lock on connection, but wait for releasing lock on abort method. Deadlock state.

How this can be fixed:

In method org.springframework.transaction.jta.JtaTransactionManager#doRollback you can check transaction state, and if it is already in state Status.STATUS_ROLLING_BACK - just do nothing.

---

Affects: 3.0.5

Attachments:

• deadlock.txt (4.89 kB)

[spring-projects-issues]

Sergey Astakhov commented

Looks like adding checking transaction state dosn't help much. Deadlocks are disappeared, but the cancelled transaction remains associated with main thread and blocked new processing in this thread. I'm also registered this bug in jboss jira, may be they can help resolving it: https://issues.jboss.org/browse/JBTM-851

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid there isn't much we can do about this from Spring's side. We absolutely have to trigger a JTA rollback invocation in order to clean up transactional state that has been associated with the current thread. FWIW, any manual interaction with a JTA UserTransaction has to do the same.

So in order to be safe with any kind of JTA usage, not just with Spring's, such a check against an in-flight rollback has to happen within the JTA provider implementation itself.

Juergen