Transactions, rollback and propagation boundaries
Prerequisites: 01-ecosystem
What does the transaction actually protect?
Goal & mental model verified
@Transactional defines an advised transaction boundary. Default rollback typically covers unchecked exceptions and Error; checked-exception behavior can be customized, including global defaults. Read-only is generally a hint, not a universal write prohibition.
[S30] [S31]Worked example · design exercise synthesis
An issuePolicy service method updates the quote and inserts the policy in one database transaction. An email call is not rolled back just because the database transaction fails.
[S30] [S31] [S19]Engineering decision synthesis
Keep boundaries around coherent database use cases and avoid long remote waits while holding connections. Choose explicit rollback policy and account for propagation and pool capacity.
[S30] [S31] [S19]Pitfall & diagnosis synthesis
Self-invocation can bypass advice. Catching and swallowing a failure can prevent expected rollback. REQUIRES_NEW can require an additional connection and therefore worsen pool pressure.
[S30] [S31] [S19]Improve & validate synthesis
Verify rollback through the proxied bean with real persistence. Exercise checked exceptions, concurrent conflicts and external side-effect failure separately.
[S30] [S31] [S19]Check yourself: Will a database rollback unsend an email?
No. External effects need separate coordination such as durable events and idempotent handling.