Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Jun 8, 2011 · 2 comments
Assignees
Labels
in: data status: declined

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jun 8, 2011

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:

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Jun 10, 2011

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
Copy link
Collaborator Author

spring-projects-issues commented Dec 11, 2011

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

@spring-projects-issues spring-projects-issues added type: bug status: declined in: data labels Jan 11, 2019
@spring-projects-issues spring-projects-issues removed the type: bug label Jan 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data status: declined
Projects
None yet
Development

No branches or pull requests

2 participants