Using declarative transaction management, which situation will cause a transaction to roll back by default?

Question

Options

• AWhen any uncaught unchecked exception is thrown
• BWhen any type of exception is thrown, checked or unchecked
• CWhen any uncaught checked exception is thrown
• DOnly when a Spring-specific exception is thrown

• A
  94% (48)
• B
  2% (1)
• C
  2% (1)
• D
  2% (1)

Explanation

In Spring's declarative transaction management (via @Transactional), a rollback is triggered by default only when an unchecked exception (i.e., RuntimeException or Error) is thrown and left uncaught - this mirrors the behavior inherited from EJB conventions, where checked exceptions are considered "expected" business conditions, not fatal errors. Option B is wrong because checked exceptions do not cause a rollback by default; Spring assumes if you declared a checked exception, you intended to handle it at the caller. Option C is the opposite of the truth - checked exceptions are exactly what Spring won't rollback for by default. Option D is wrong because Spring does not require its own exception types; any unchecked exception (including plain RuntimeException) triggers the rollback.

Memory tip: Think "unchecked = unexpected = undo." If the exception is unchecked, Spring treats it as a crash-worthy problem and rolls back. You can override this with rollbackFor / noRollbackFor on @Transactional, but the default follows the "unchecked = rollback" rule.

No community discussion yet for this question.