Transaction Management

It is Spring's PlatformTransactionManager for a single JDBC DataSource. It opens a database Connection, turns off auto-commit, and commits or rolls back when the transaction ends. Use it with JdbcTemplate or MyBatis.

JpaTransactionManager is Spring's PlatformTransactionManager for JPA. It opens an EntityManager, starts a transaction on it, and commits or rolls back when a @Transactional method finishes. Use it when your app persists data through JPA/Hibernate.

By default Spring needs one clear choice. To pick a specific manager, pass its bean name as a qualifier: @Transactional("orderTxManager") or @Transactional(transactionManager = "orderTxManager").

It is Spring's central interface for managing transactions. It defines three methods: getTransaction (start/join a transaction), commit (make changes permanent), and rollback (undo changes).

ReactiveTransactionManager runs transactions for non-blocking code, returning Mono results instead of blocking. PlatformTransactionManager is the classic blocking one for imperative code (JDBC/JPA). You pick the one matching your stack.

@Transactional tells Spring to run the method inside a database transaction: Spring starts a transaction before the method, commits if it returns normally, and rolls back if it throws a runtime exception.

It sets how much one transaction is shielded from data other in-flight transactions are changing. Spring's Isolation enum offers DEFAULT, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, and SERIALIZABLE — higher levels give more consistency but less concurrency.

It marks a transaction as read-only: a hint that the method only reads data. Spring passes this to Hibernate and the JDBC driver so they can optimize, for example by skipping dirty-checking and the automatic flush.

By default Spring rolls back on unchecked exceptions (RuntimeException) and Error. It commits on checked exceptions (any Exception that isn't a RuntimeException). You must opt in to roll back on checked exceptions.

@Transactional(timeout = N) limits how long the transaction may run to N seconds. If it exceeds that, Spring aborts it and rolls back, throwing a TransactionTimedOutException. The unit is always seconds.

NOT_SUPPORTED runs the method without a transaction. If a transaction is already active, Spring pauses (suspends) it, runs the method non-transactionally, then resumes the paused transaction afterward.

REQUIRED is the default propagation. If a transaction is already running, the method joins it; if none exists, Spring starts a new one. So the code always runs inside exactly one transaction.

REQUIRES_NEW always starts a brand-new, independent transaction. If a transaction is already running, Spring pauses (suspends) it, runs the new one on its own database connection, then resumes the old one.

SUPPORTS joins an existing transaction if one is active, otherwise runs without one. MANDATORY requires an active transaction and throws if none exists. NEVER requires that no transaction is active and throws if one exists.

REQUIRES_NEW opens a separate transaction that commits on its own, surviving an outer rollback. NESTED stays inside one transaction using a savepoint; nested work is lost if the outer rolls back. Use REQUIRES_NEW for truly independent commits, NESTED for partial rollback within one unit.

TransactionalOperator is a helper that wraps a Mono or Flux in a transaction. Reactive code hops threads, so the classic ThreadLocal transaction doesn't work; the operator carries the transaction in the Reactor Context instead. It commits on success, rolls back on error.

TransactionStatus is a handle to the current transaction that PlatformTransactionManager gives you. Calling setRollbackOnly() marks the transaction so it can only roll back — commit will not succeed.

TransactionTemplate runs a block of code inside a database transaction programmatically. You call execute() and pass a callback; Spring starts a transaction, runs your code, then commits or rolls back. Use it when you need transaction control in code rather than the @Transactional annotation.

Get a TransactionStatus, do the work, and commit inside try. In catch, call rollback(status) and rethrow. If you forget rollback, a failed transaction stays open and the connection may leak or auto-commit dirty data.

It commits when the wrapped publisher completes normally (onComplete). It rolls back if the publisher emits an error (onError). If the subscription is cancelled before completing, it also rolls back.

No. @Async runs the method on a different thread, and Spring ties a transaction to the thread that started it. So the async code runs in its own separate transaction (or none), not the caller's.

By default Spring COMMITS the transaction. Spring only rolls back automatically on unchecked exceptions (RuntimeException and Error). A checked exception like IOException does not trigger a rollback unless you configure it.

It's a Hibernate error thrown when you access a lazily-loaded field (like a list of orders) after the database session has already closed. The service's transaction ended, so Hibernate can't fetch the data anymore.

Spring adds transactions with a proxy — a wrapper object around your bean. The proxy can only intercept public methods it can override. Private methods can't be overridden, so the annotation is skipped with no error.

REQUIRES_NEW starts a brand-new, independent transaction. If one is already running, Spring suspends it (keeps it open) and opens a second database connection for the new one, so the thread holds two connections at once.

Because the transaction might still roll back. If you email or publish before commit and the transaction then fails, you have acted on data that was never saved. Waiting until after commit ensures the side effect only happens for data that actually persisted.

It's a Spring event listener that only fires relative to a transaction. By default it runs in the AFTER_COMMIT phase, so it executes only after the surrounding transaction successfully commits.

You publish an event inside the transaction; a method annotated @TransactionalEventListener runs it after the transaction commits (AFTER_COMMIT is the default phase). Gotchas: if there is no active transaction the event is dropped unless fallbackExecution=true, and DB writes in the listener need a new transaction.

BEFORE_COMMIT fires just before commit (still in the tx). AFTER_COMMIT (default) fires after a successful commit. AFTER_ROLLBACK fires after a rollback. AFTER_COMPLETION fires after the tx ends either way.

Register a TransactionSynchronization callback via TransactionSynchronizationManager.registerSynchronization(...) and override afterCommit(). Spring invokes it only if the current transaction commits successfully.