Spring Boot Transaction Management

No. When you add a starter such as spring-boot-starter-data-jpa or spring-boot-starter-jdbc, Spring Boot’s auto-configuration switches transaction support on and creates the matching transaction manager. Adding the annotation does no harm, but it is not needed.

You only need it in plain Spring applications without Spring Boot, or in rare cases where you want to change how the transaction proxies are created.

Spring supports both, but they are different annotations:

In Spring applications, use Spring’s version: it offers more options. IDEs often suggest both when you type @Transactional, so check the import.

An inner @Transactional method that joined the outer transaction (the default REQUIRED) threw an exception. Spring marked the whole shared transaction as “rollback-only”. The outer method then caught the exception and tried to finish normally, but the transaction can no longer commit, so Spring throws UnexpectedRollbackException:

@Transactional
public void processBatch(List<Order> orders) {
    for (Order order : orders) {
        try {
            orderProcessor.process(order);   // @Transactional (REQUIRED) - joins this transaction
        } catch (InvalidOrderException ex) {
            log.warn("Skipping order {}", order.getId());   // swallowing does not help
        }
    }
}   // UnexpectedRollbackException here

If each item should succeed or fail on its own, give the inner method Propagation.REQUIRES_NEW, or validate before entering the transaction.

Use REQUIRES_NEW for work that must survive no matter what, like audit logs. Use NESTED when part of a job may fail without spoiling the rest, but everything should still commit or roll back together at the end. NESTED relies on database savepoints, which JDBC-based transaction managers support.

Not atomically by default. With two data sources, you have two transaction managers, and a method uses only one of them, chosen by name:

@Transactional("ordersTransactionManager")
public void placeOrder(Order order) { ... }

@Transactional("billingTransactionManager")
public void createInvoice(Invoice invoice) { ... }

If both databases must change together, you need a distributed transaction (JTA/XA, with a separate transaction coordinator), which adds complexity and slows things down. Most teams instead design for it: one database per business operation, or a series of local steps with compensating actions if one fails.

No. A database transaction lives inside one service and one database. When an order service calls a payment service over HTTP, the payment service commits its own transaction, and the order service cannot roll it back.

Microservices use the Saga pattern instead: each service commits a local transaction, and if a later step fails, earlier steps are undone by compensating actions, such as “refund the payment”. See the Saga Pattern tutorial.

Usually not, with the common default isolation levels:

• Writes (update, delete) lock the affected rows until the transaction ends.
• Plain reads do not lock rows under READ_COMMITTED in most databases; other transactions can still change them.

If you must stop others from changing a row you just read, either use optimistic locking with @Version, which detects conflicting changes, or explicitly lock it:

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT a FROM Account a WHERE a.number = :number")
Optional<Account> findForUpdate(@Param("number") String number);   // SELECT ... FOR UPDATE

Turn on debug logging for the transaction classes:

logging.level.org.springframework.transaction=DEBUG
logging.level.org.springframework.orm.jpa.JpaTransactionManager=DEBUG

Creating new transaction with name [com.javabytechie.bank.TransferService.transfer]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
Committing JPA transaction on EntityManager [...]

This shows exactly which methods start, join or roll back transactions, and quickly reveals problems such as a method that never gets a transaction because of self-invocation. Switch it off again afterwards, as it is very detailed.

Inside a transaction, JPA keeps track of every entity it loaded. At commit time, it compares each entity with its original state and writes any changes automatically. This is called dirty checking:

@Transactional
public void changeEmail(Long customerId, String newEmail) {
    Customer customer = customerRepository.findById(customerId).orElseThrow();
    customer.setEmail(newEmail);   // UPDATE is executed automatically at commit
}

It also means accidental changes to a loaded entity are saved too. If a method should only read, mark it readOnly = true, and avoid changing entities you only meant to display.

Yes, for two reasons:

• It holds resources. While waiting for the remote API, perhaps for seconds, your transaction keeps a database connection and any locks. A slow partner can then exhaust your connection pool.
• It cannot be undone. If your transaction rolls back afterwards, the remote call has still happened.

Call remote services before the transaction, using the result inside it, or after the commit, for example with @TransactionalEventListener, so the transaction stays short and only contains database work.

Not reliably. It is mainly a performance hint. Hibernate skips change detection and flushing, so changes to loaded entities are usually just not saved, without any error.

Whether the database itself rejects writes depends on the database and driver. Some, such as PostgreSQL, raise an error for an INSERT in a read-only transaction; others may allow it. Never rely on readOnly as a security or safety mechanism; use it to express intent and gain performance.

Yes. For methods returning Mono or Flux, Spring uses a reactive transaction manager, such as R2dbcTransactionManager with R2DBC:

@Transactional
public Mono<Void> transfer(String from, String to, BigDecimal amount) {
    return accounts.withdraw(from, amount)
            .then(accounts.deposit(to, amount));
}

The transaction is tied to the reactive pipeline rather than to a thread. Blocking JPA calls do not belong in reactive code, because they would block the few event-loop threads that WebFlux relies on.

A savepoint is a marker inside a transaction. You can roll back to it, undoing only the work done after it, while keeping the work before it and continuing the transaction.

transactionTemplate.executeWithoutResult(status -> {
    saveHeader(statement);
    Object savepoint = status.createSavepoint();
    try {
        saveOptionalDetails(statement);
    } catch (DataAccessException ex) {
        status.rollbackToSavepoint(savepoint);   // undo only the details
    }
});

Propagation.NESTED uses savepoints for you automatically. Savepoints are supported by most relational databases through JDBC.

A deadlock happens when two transactions each wait for a lock that the other holds. For example, transaction 1 locks account A and wants B, while transaction 2 locks B and wants A. The database detects this and aborts one of them with an error.

To make deadlocks rare:

• Lock rows in a consistent order, for example always the lower account number first.
• Keep transactions short, so locks are held briefly.
• Retry the whole transaction a few times when the database reports a deadlock.

// Always lock accounts in the same order, whatever the transfer direction
String first = from.compareTo(to) < 0 ? from : to;
String second = first.equals(from) ? to : from;
accountRepository.findForUpdate(first);
accountRepository.findForUpdate(second);

Put it on concrete classes or their methods. Current Spring versions also detect it on interfaces, but annotating the implementation is what Spring recommends: it works with every proxy type and makes the transactional behavior visible right where the code is.

The exception that leaves the method, because that is the one the proxy sees:

@Transactional
public void importFile(Path path) {
    try {
        Files.readAllLines(path).forEach(this::importLine);
    } catch (IOException ex) {
        throw new ImportFailedException(path, ex);   // unchecked -> rollback
    }
}

Wrapping a checked exception in an unchecked one, as here, is a common way to get a rollback without extra settings. Keep the original as the cause, so the real reason stays visible in the logs.

@TransactionalEventListener(AFTER_COMMIT) sends it after the commit, but if the application crashes between the commit and the send, the message is lost.

When every message must be delivered, use the transactional outbox pattern:

1. In the same transaction as your business change, insert the message into an outbox table.
2. A separate process reads new rows from the outbox and publishes them to the broker, such as Kafka.
3. It marks each row as sent once the broker confirms.

Because the business data and the outbox row commit together, a message can never be lost or sent for a rolled-back change.

Each transaction holds a database connection from the pool for its whole duration. Spring Boot’s default pool (HikariCP) has 10 connections. If transactions are slow, for example because they call remote services or process large files, requests start waiting for a free connection.

Fix the cause first: keep transactions short and move slow work outside them. Then size the pool for your load:

spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.connection-timeout=5000

A bigger pool is not always better, because the database can handle only so many parallel connections. Watch the pool metrics through Actuator before changing it.

Not strictly, since each query also runs on its own. But @Transactional(readOnly = true) brings real benefits:

• Consistency: several queries in one method see the same snapshot of data, depending on the isolation level.
• Lazy loading works inside the method, because the persistence context stays open.
• Performance: Hibernate skips change detection.
• One connection is used for all the queries, instead of one per query.

A common pattern is @Transactional(readOnly = true) on the service class, with plain @Transactional on the methods that write.

Calling flush() early is useful when you want database errors, such as a duplicate key, to appear at a specific point in your method instead of at the very end. It never replaces the commit.