Manager-Driven Transactions

## The canonical shape ```java TransactionStatus status = txManager.getTransaction(def); try { doWork(); txManager.commit(status); } catch (RuntimeException ex) { txManager.rollback(status); throw ex; } ``` Every element matters, so let's dissect the failure modes. ## Failure mode 1 — forgetting rollback Unlike `@Transactional`, the manager applies **no automatic rollback rules**. If an exception escapes the `try` and you never call `rollback(status)`, the transaction is neither committed nor rolled back by Spring. Depending on the manager and connection pool, the physical connection may be returned to the pool with an open transaction, get rolled back later on close, or in a misconfigured setup even auto-commit partial work. At minimum you risk holding locks and connections until a timeout. ## Failure mode 2 — swallowing the exception If you `rollback(status)` but then **do not rethrow**, the caller sees a normal return and assumes the work committed. Almost always you should rethrow (or throw a translated exception) after rollback so the failure is visible. ## Failure mode 3 — catch too narrow Catching only, say, `BusinessException` means a `RuntimeException` (NPE, `DataAccessException`, `OptimisticLockingFailureException`) propagates past the `catch` with **no rollback**. Because you own the rollback decision, the catch must be broad enough. `catch (RuntimeException ex)` covers Spring's `DataAccessException` hierarchy (all unchecked). Use `catch (Throwable t)` only if you deliberately want to roll back on `Error` and checked exceptions too — and rethrow appropriately. ## Failure mode 4 — commit() throws `txManager.commit(status)` can throw — e.g. deferred constraint violation surfaced at flush/commit, or `TransactionSystemException`. Importantly, when `commit()` fails, Spring already rolls the transaction back internally, so you must **not** call `rollback(status)` again on that same status (it's already completed). A defensive pattern separates the two: ```java TransactionStatus status = txManager.getTransaction(def); try { doWork(); } catch (RuntimeException ex) { txManager.rollback(status); // work failed before commit throw ex; } txManager.commit(status); // may throw; already rolled back internally on failure ``` Here rollback covers only the work phase; the commit is outside the catch so a commit failure isn't double-handled. ## setRollbackOnly as an alternative signal Instead of exceptions, you can mark `status.setRollbackOnly()` from inner logic; the eventual `commit(status)` then performs a rollback (and Spring may throw `UnexpectedRollbackException` to signal the silent rollback). This mirrors how nested `@Transactional` participation flags a rollback. ## Why this is error-prone All four failure modes are exactly why Spring recommends `TransactionTemplate` for single blocks: it runs your callback, commits on normal return, and automatically rolls back on `RuntimeException`/`Error` (or when you call `status.setRollbackOnly()`), removing the hand-written catch. Direct manager use is warranted only when you need boundaries the template can't express.