Demo: the REQUIRES_NEW audit-log trap
On This Lesson 3 topics
This lesson is planned. The outline below lists the topics it will cover. The full lesson has not been published yet.
In this lesson
show how REQUIRES_NEW interacts with pool size and rollbacks.
Draft outline details
Step by step
- An
OrderService.placecallsAuditService.logannotatedREQUIRES_NEWso the audit row survives order failure. - Show it works: order fails, audit row persists.
- Set pool size to 2 and run 5 concurrent requests: each holds one connection and waits for a second; threads time out (pool deadlock).
- Planned mistake: call the audit method from within the same class; no new transaction starts (proxy bypass). Fix: move it to another bean.
- Fix the pool problem: record audit events after commit (
@TransactionalEventListener(AFTER_COMMIT)or an outbox table) instead of nesting.
Check your understanding
What is a safer way to keep an audit row independent of the order outcome?
Show answer
Write it outside the outer transaction, for example after commit or via an outbox.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.