Mastering Spring @Transactional: Exception Types and Rollback Strategies

1. Exception Classification

First, let's look at exception classification.

Errors always trigger a rollback.

Exceptions are divided into runtime exceptions ( RuntimeException) and non‑runtime exceptions.

Checked exceptions: all Exception subclasses except RuntimeException.

Unchecked exceptions: RuntimeException and its subclasses, plus Error.

If a runtime exception is not handled, the thread or the main program may terminate; to avoid termination, all runtime exceptions must be caught.

When exception data appears in a queue, normal processing should discard the faulty data and log it, without affecting subsequent normal data.

Non‑runtime exceptions (e.g., IOException, SQLException, custom Exception) are subclasses of Exception. The Java compiler forces you to catch them, otherwise the code won't compile, requiring many try‑catch blocks.

2. Writing @Transactional

Spring's transaction infrastructure rolls back only for runtime and unchecked exceptions by default.

When a RuntimeException (or its subclass) is thrown, the transaction rolls back; Error behaves the same. Checked exceptions do not trigger a rollback.

Make checked exceptions roll back: @Transactional(rollbackFor=Exception.class) Prevent unchecked exceptions from rolling back: @Transactional(notRollbackFor=RuntimeException.class) Methods that don't need transaction management (read‑only):

@Transactional(propagation=Propagation.NOT_SUPPORTED)

Note: If an exception is caught with try{ }catch{ } , the transaction will not roll back; you must re‑throw the exception to trigger a rollback.

Note

The Spring team recommends placing @Transactional on concrete classes (or their methods) rather than on interfaces.

You can annotate an interface, but it only works when using interface‑based proxies.

Annotations are not inheritable, so class‑based proxies will ignore @Transactional on interfaces.

Keep methods annotated with @Transactional simple; avoid putting heavy logic or locks inside a transaction. Perform regular queries before the transaction and reserve the transaction for insert, update, delete, or locked queries.

rollbackFor can specify which exception types trigger a transaction rollback; by default, Spring rolls back for unchecked exceptions and Error only.

If you want the transaction to roll back for other exception types, you must set the rollbackFor attribute accordingly.