Transactions & Propagation

No. Declarative transactions are applied by a proxy around a Spring bean. The proxy only intercepts calls arriving through it to methods it can override, so new-created objects, private, and final methods (CGLIB cannot override them) get no transaction and fail silently.

• Annotate public methods on beans; since Spring 6, protected and package-private methods are also supported with class-based (CGLIB) proxies.
• Check with TransactionSynchronizationManager.isActualTransactionActive() or by logging org.springframework.transaction at DEBUG.
• Put @Transactional on the service layer, not controllers or repository interfaces' callers' internals.

Self-invocation bypasses the proxy, so the REQUIRES_NEW annotation is never evaluated; saveAudit() runs inside the caller's transaction and rolls back with it.

Fix by moving it to a separate bean:

@Service
class AuditService {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void save(AuditEvent e) { repo.save(e); }
}

Alternatives: self-injection, TransactionTemplate inside the method, or AspectJ mode.

By default Spring rolls back only on unchecked exceptions (RuntimeException and Error). A checked exception commits whatever was flushed. Declare rollbackFor = Exception.class (or specific types) to roll back on checked ones.

@Transactional(rollbackFor = IOException.class)
public void importFile(Path p) throws IOException { ... }

This rule mirrors EJB convention. noRollbackFor does the inverse.

With REQUIRED, inner and outer share one physical transaction. When the inner proxy sees a runtime exception, it marks the shared transaction rollback-only. Catching the exception outside does not clear the mark, so the outer commit attempt becomes a rollback and Spring reports UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only.

Solutions: use REQUIRES_NEW (or NESTED with savepoints) for the part that may fail independently, or avoid calling a transactional bean that throws when you intend to recover.

Behaviour when a transaction already exists / does not:

• REQUIRED (default): join / create new.
• REQUIRES_NEW: suspend current and create new / create new.
• NESTED: savepoint within current / create new (like REQUIRED).
• SUPPORTS: join / run non-transactionally.
• MANDATORY: join / throw IllegalTransactionStateException.
• NOT_SUPPORTED: suspend and run non-transactionally / non-transactionally.
• NEVER: throw / non-transactionally.

sendEmail()'s transaction is independent. If it already committed before the later failure, its changes persist while placeOrder() rolls back; if it throws, only its own transaction rolls back, and the exception propagating into placeOrder() rolls the outer one back too (unless caught).

• REQUIRES_NEW suspends the outer transaction and uses a second connection from the pool.
• Inner commits are not undone by an outer rollback, so use it only for facts that must persist (audit, failure log).

NESTED creates a JDBC savepoint inside the existing transaction. If the nested part throws and you catch it, Spring rolls back to the savepoint and the outer work continues and can commit; the whole thing is still one physical transaction and one connection.

• Works with DataSourceTransactionManager and JpaTransactionManager only when the JDBC driver supports savepoints.
• Hibernate: after a rollback to savepoint the persistence context may be in an inconsistent state (entities from the failed part are still managed), so NESTED with JPA is risky; JDBC-based code is cleaner.
• If the outer transaction rolls back, nested work rolls back too.

This is a lost update: both read the same value, and the last write wins. READ_COMMITTED does not prevent it. Options: optimistic locking (@Version, retry on ObjectOptimisticLockingFailureException), pessimistic locking (SELECT ... FOR UPDATE via @Lock(PESSIMISTIC_WRITE)), an atomic update (UPDATE account SET balance = balance - :x WHERE id = :id AND balance >= :x), or SERIALIZABLE with retry.

• Phenomena by level: dirty read (READ_UNCOMMITTED), non-repeatable read and phantom (READ_COMMITTED), phantom (REPEATABLE_READ in the standard; PostgreSQL's snapshot isolation prevents phantoms but permits write skew).
• Defaults: PostgreSQL and Oracle READ_COMMITTED, MySQL InnoDB REPEATABLE_READ.

It is a hint, not an enforcement. With Hibernate it sets the session flush mode to MANUAL (no dirty checking flush at commit, skipping snapshot comparison), and passes Connection.setReadOnly(true) so some drivers and routing datasources send it to a replica. Writes may still succeed on some databases.

• Benefits: less memory and CPU for large result sets, safer read paths, replica routing.
• Pitfalls: a nested readOnly=false call joining a readOnly=true outer transaction does not become writable, and writes may be silently not flushed.
• PostgreSQL enforces read-only (cannot execute INSERT in a read-only transaction); MySQL behaviour varies.

Spring's timeout is a deadline checked when it next interacts with the resource (Spring sets the JDBC statement query timeout or checks before the next statement/flush). Pure CPU work, remote HTTP calls, or Thread.sleep inside the method do not consume or trigger it.

• It applies only to the transaction's database operations; the TransactionTimedOutException appears at the next DB call after expiry.
• Also set connection-level and statement timeouts (socketTimeout, jakarta.persistence.query.timeout) and HTTP client timeouts.
• Does not apply to joined participating transactions; the outer defines it.

Under Hibernate, the transaction (and typically the connection, depending on release mode) is held for the duration of the call. Slow remote calls hold pooled connections and row locks, so the pool exhausts and other requests wait, causing cascading timeouts.

• Do the remote call outside the transaction, then open a short transaction for the DB write (TransactionTemplate or a separate bean).
• If the remote result must be atomic with DB changes, use the outbox or a saga rather than a long transaction.
• Monitor with Hikari metrics (hikaricp.connections.pending, usage).

Transactions are bound to the thread via TransactionSynchronizationManager (ThreadLocal). The @Async method runs on another thread with no transaction (or its own, if annotated), and the caller's data is not committed yet, so it is invisible under READ_COMMITTED.

• Trigger async work after commit, via @TransactionalEventListener(phase = AFTER_COMMIT) or TransactionSynchronization.afterCommit.
• Pass ids, not entities, to async methods; load in the new transaction (detached entities cause LazyInitializationException).
• Security context and MDC also need explicit propagation (DelegatingSecurityContextAsyncTaskExecutor, TaskDecorator).

@EventListener runs synchronously inside the publisher's transaction; its failure rolls the publisher back. @TransactionalEventListener is bound to a phase of the current transaction: BEFORE_COMMIT, AFTER_COMMIT (default), AFTER_ROLLBACK, AFTER_COMPLETION.

• If no transaction is active when the event is published, the listener is skipped unless fallbackExecution = true.
• In AFTER_COMMIT, the original transaction is committed but its resources may still be bound; DB work in the listener needs @Transactional(propagation = REQUIRES_NEW) or the changes are never committed (Spring 6.1 requires explicit propagation for writes).
• An exception in AFTER_COMMIT does not roll back the already committed data and is only logged.

Register a TransactionSynchronization on the current transaction.

TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
    @Override public void afterCommit() { publisher.publish(orderId); }
});

Callbacks: beforeCommit, beforeCompletion, afterCommit, afterCompletion(status). Registration requires an active synchronization (isSynchronizationActive()), otherwise IllegalStateException.

• Exceptions in afterCommit propagate to the caller but cannot undo the commit.
• Use for cache eviction, sending messages after success, or releasing resources.

Use the transactional outbox pattern: in the same local DB transaction, write the business rows and an outbox row (event payload). A separate relay (poller or CDC such as Debezium) publishes outbox rows to the broker and marks them sent. This gives at-least-once delivery, so consumers must be idempotent.

@Transactional
public void place(Order o) {
    orders.save(o);
    outbox.save(new OutboxEvent("OrderPlaced", o.getId(), json(o)));
}

Alternatives: 2PC/XA (poor availability and brokers rarely support it), sagas for multi-service workflows with compensations.

The lazy association is accessed after the transaction (and persistence context) closed, so Hibernate cannot load it. The session lives only for the transaction unless Open Session In View is on.

Fixes, in order: fetch what you need inside the service (JOIN FETCH, @EntityGraph), map to a DTO inside the transaction, or use a projection query. Avoid enabling open-in-view or enable_lazy_load_no_trans, which cause N+1 queries and long-held connections.

Transaction boundaries should wrap a business use case: after validation and before response serialization. At controller level, the transaction also spans request parsing, serialization, and slow downstream calls, holding connections longer and mixing transport concerns with data consistency.

• A rollback caused by serialization failing after commit logic is confusing.
• Service-level transactions can be reused by jobs, listeners, and tests.
• Use one transactional facade per use case and keep inner services REQUIRED or MANDATORY when they must not run alone.

Inside a transaction, entities loaded or saved are managed. Hibernate compares their state with the snapshot at flush (before commit or before queries) and issues UPDATE automatically (dirty checking). No explicit save is needed for managed entities.

• Outside a transaction (or with readOnly=true), changes are not flushed.
• save() on a detached entity does merge, returning a different managed instance; keep using the returned object.
• flush timing: FlushModeType.AUTO flushes before JPQL queries touching the affected tables.

The SQL executes at flush time, usually at transaction commit, which happens after your method returns (in the proxy). The exception therefore surfaces to the caller of the transactional method, outside your try/catch.

Options: call saveAndFlush() / entityManager.flush() inside the try; catch at the layer calling the transactional service; or handle in @ControllerAdvice mapping to 409. After a persistence exception the Hibernate session is unusable and the transaction is marked rollback-only, so retry in a new transaction.

@Transactional uses one PlatformTransactionManager (the primary, or the one named in @Transactional("billingTm")). Only that datasource is in the transaction; writes to the other autocommit, so a failure leaves them inconsistent.

• ChainedTransactionManager is deprecated and removed in Spring Data 3.x, and gave only best-effort commit.
• Options: JTA/XA (Atomikos, Narayana; heavy, 2PC), an eventually consistent saga with compensation, or the outbox between the two.
• Declare multiple managers explicitly and mark one @Primary, otherwise NoUniqueBeanDefinitionException.

The persistence context holds every loaded entity (plus snapshots) for the whole transaction. Process in chunks with a small transaction per chunk, clear the context (em.flush(); em.clear();) periodically, or use projections/streaming read-only queries.

• Chunk by keyset (id range), commit per chunk via TransactionTemplate; failures then affect one chunk.
• Set hibernate.jdbc.batch_size and order_inserts for writes; IDENTITY generation disables insert batching.
• For serious batch work, consider Spring Batch with chunk-oriented steps and restartability.

@Scheduled methods are invoked by the scheduler on the bean from the context. If the bean is proxied (transactional), the scheduler calls through the proxy, so it usually works. Problems come from self-invocation (a scheduled method calling a private/this transactional method), a non-proxyable class, or an exception swallowed in the job.

• Each run is a fresh transaction on a scheduler thread; the default scheduler has a single thread, so one slow job blocks others (spring.task.scheduling.pool.size).
• In multi-instance deployments the job runs on every node; use ShedLock or a leader/DB lock.

In one transaction the second call returns the same managed instance from the first-level cache without a second SQL query (for findById; JPQL queries always hit the DB but resolve to the same instances). In two transactions, two persistence contexts load two separate instances, each with its own SQL.

• The cache is per EntityManager, scoped to the transaction.
• Within a REPEATABLE_READ/READ_COMMITTED transaction, repeated queries may show different DB state, but the entity returned for a loaded id stays the stale managed copy; use refresh to re-read.

@Transactional on a Spring test wraps the whole test in a transaction that is rolled back at the end. That keeps one persistence context open across test code, hiding lazy-loading errors, and never commits, so AFTER_COMMIT listeners, DB triggers, constraint checks at commit, and outbox pollers never run.

• For such behaviour, omit @Transactional on the test and clean data explicitly, or use @Commit/TestTransaction.flagForCommit().
• Use Testcontainers to match the real DB's isolation and constraints rather than H2.
• @DataJpaTest is transactional and rolls back by default.

Optimistic locking uses a @Version column; the update statement includes WHERE version = ?, and a mismatch throws ObjectOptimisticLockingFailureException. It suits low-contention data. Pessimistic locking (@Lock(PESSIMISTIC_WRITE) -> SELECT ... FOR UPDATE) blocks others and suits high contention or short critical sections.

• Retry the entire transaction (not just the failed statement) with a bounded count and jitter; @Retryable (spring-retry) must wrap the transactional proxy, so set @EnableRetry(order) / aspect order so retry is outside the transaction.
• Pessimistic lock timeouts: jakarta.persistence.lock.timeout hint; use SKIP LOCKED for work queues.

The DB aborts one victim (DeadlockLoserDataAccessException / CannotAcquireLockException). Prevent by acquiring locks in a consistent global order (for example, sort ids ascending before updating), keeping transactions short, and using appropriate indexes so fewer rows are locked.

• Handle by retrying the whole transaction on deadlock exceptions.
• Avoid user interaction or remote calls inside the transaction.
• Inspect with DB tools (SHOW ENGINE INNODB STATUS, pg_locks/pg_stat_activity).

Boot auto-configures JpaTransactionManager when JPA is present (otherwise DataSourceTransactionManager for JDBC) and enables @EnableTransactionManagement through TransactionAutoConfiguration; no annotation is needed.

• JpaTransactionManager binds both the EntityManager and the JDBC connection, so JdbcTemplate and JPA calls share one transaction in the same DataSource.
• Proxy type follows spring.aop.proxy-target-class (true by default).
• Reactive apps use ReactiveTransactionManager (R2DBC); the thread-bound model does not apply.