Propagation and rollback rules

When one transactional method calls another through a proxy, the propagation setting of the called method decides whether it joins the caller's transaction or gets its own.

REQUIRED means the inner method's work and the outer method's work commit or roll back together — there is one physical transaction. REQUIRES_NEW gives the inner method a separate transaction (and a separate database connection) that commits or rolls back on its own, which is what you want for an audit record that must survive the caller's failure. NESTED rolls back to a savepoint without abandoning the outer transaction; it needs a transaction manager with savepoint support, such as DataSourceTransactionManager.

Which exceptions roll back

By default the proxy rolls back when the method throws an unchecked exception — a RuntimeException or an Error, or any subclass — and commits when it throws a checked exception. The checked exception still propagates to the caller; the transaction is simply committed first. Change the rule per method with rollbackFor and noRollbackFor:

@Transactional(rollbackFor = Exception.class)   // checked exceptions roll back too
public void importFile(Path p) throws IOException { ... }

1import java.io.IOException;2import java.util.*;3 4public class Solution {5    static boolean rollsBackByDefault(Throwable t) {6        return t instanceof RuntimeException || t instanceof Error;7    }8 9    static boolean rollsBack(Throwable t, List<Class<? extends Throwable>> rollbackFor) {10        for (Class<? extends Throwable> c : rollbackFor) if (c.isInstance(t)) return true;11        return rollsBackByDefault(t);12    }13 14    public static List<String> run() {15        List<Throwable> thrown = List.of(16            new IllegalStateException("bad state"),17            new IOException("disk full"),18            new StackOverflowError(),19            new Exception("checked"));20        List<String> out = new ArrayList<>();21        for (Throwable t : thrown) {22            out.add(t.getClass().getSimpleName()23                + ": default=" + (rollsBackByDefault(t) ? "ROLLBACK" : "COMMIT")24                + ", rollbackFor=Exception=" + (rollsBack(t, List.of(Exception.class)) ? "ROLLBACK" : "COMMIT"));25        }26        return out;27    }28}

If the method catches the exception itself and returns normally, the proxy never sees it and commits.

UnexpectedRollbackException

With REQUIRED, the inner method has no transaction of its own to roll back. When it throws an unchecked exception, its proxy marks the shared transaction rollback-only. If the outer method catches that exception and carries on, it returns normally and its proxy tries to commit — but the transaction is rollback-only. Spring rolls back and throws UnexpectedRollbackException to the outer method's caller, so the "handled" failure turns into an error one level higher.

1import java.util.*;2 3public class Solution {4    static final class Tx { boolean rollbackOnly; }5    static final List<String> log = new ArrayList<>();6    static Tx current;7 8    // What the proxy does around a REQUIRED method.9    static void required(String name, Runnable body) {10        boolean outermost = current == null;11        if (outermost) { current = new Tx(); log.add(name + ": begin"); }12        else log.add(name + ": join");13        try {14            body.run();15        } catch (RuntimeException e) {16            if (outermost) { log.add(name + ": rollback"); current = null; }17            else { current.rollbackOnly = true; log.add(name + ": mark rollback-only"); }18            throw e;19        }20        if (outermost) {21            Tx tx = current; current = null;22            if (tx.rollbackOnly) {23                log.add(name + ": rollback");24                throw new IllegalStateException("UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only");25            }26            log.add(name + ": commit");27        }28    }29 30    public static List<String> run() {31        try {32            required("placeOrder", () -> {33                try {34                    required("reserveStock", () -> { throw new IllegalArgumentException("out of stock"); });35                } catch (IllegalArgumentException e) {36                    log.add("placeOrder: caught '" + e.getMessage() + "', carrying on");37                }38            });39            log.add("caller: success");40        } catch (IllegalStateException e) {41            log.add("caller got " + e.getMessage());42        }43        return log;44    }45}

If the outer method genuinely should continue after the inner failure, the inner work needs its own transaction (REQUIRES_NEW), or the failure must be prevented or signalled without an unchecked exception crossing the inner proxy.

Common mistakes

• Expecting throws IOException from a @Transactional method to roll back: by default it commits, as the first example shows.
• Catching an exception from a joined REQUIRED call and expecting the outer transaction to commit.
• Using REQUIRES_NEW inside a loop or under load: each call holds a second connection while the first is suspended, and the pool can run dry.

What interviewers ask

• Difference between REQUIRED and REQUIRES_NEW? — join versus an independent, separately committed transaction; the outer one is suspended meanwhile.
• Does @Transactional roll back on a checked exception? — no, only on unchecked exceptions and errors unless rollbackFor says so.
• When do you get UnexpectedRollbackException? — an inner joined call marked the transaction rollback-only and the outer method swallowed the exception and tried to commit.