Skip to content
Preptima
hardConceptScenarioMidSeniorStaff

A method with REQUIRES_NEW was meant to save an audit row even when the main transaction fails. When does it work, and when does it deadlock?

REQUIRES_NEW suspends the caller's transaction and commits the audit on a second connection, so the row survives a later rollback if the call goes through the Spring proxy. It hangs when the audit touches rows the suspended transaction has locked, or when every thread holds one pooled connection and waits for another.

5 min readUpdated 2026-10-10Target archetype: Enterprise Captive, Product Startup

Answer

Short answer

It works when the audit method lives on a different Spring bean. The call then goes through the transaction proxy, the caller's transaction is suspended, and the audit commits on its own connection before the main work fails. With that transaction propagation, the row survives the outer rollback. It hangs in two cases. The first is when the audit needs a row lock the suspended outer transaction still holds. The second is when the connection pool has no second connection to give, because every thread is holding one.

Was this answer helpful?

Likely follow-ups

  • Why does catching an exception thrown by the REQUIRES_NEW audit not mark the outer transaction rollback-only?
  • How would you write the audit from an after-rollback event listener, and which propagation does that listener need?
  • Your audit entity references an order the outer transaction inserted a moment ago. What happens when the inner transaction commits?
  • Under JTA, what does the transaction manager need before REQUIRES_NEW can suspend anything?

Related questions

Further reading