Rollback Rules & Pitfalls

@Transactional silently fails to roll back in four cases: checked exceptions commit by default, self-invocation bypasses the proxy, private methods are ignored, and swallowed exceptions cause a commit.

UnexpectedRollbackException occurs when an inner REQUIRED method marks the shared physical transaction as rollback-only, and the outer method catches the exception and tries to commit -- the commit fails because the transaction is already doomed.

@Transactional rolls back database changes but cannot roll back emails, SMS messages, HTTP calls, or any external side effect -- fire side effects only after a confirmed commit using @TransactionalEventListener(AFTER_COMMIT).

@Transactional(readOnly=true) switches Hibernate to manual flush mode, which silently discards all pending INSERT and UPDATE statements with no error -- never let a write method inherit a class-level readOnly.

If the transaction rolled back, the API must never say 200 OK -- the HTTP status must be a faithful mirror of the committed transaction outcome, not a hopeful guess made before the commit.