Transactions (@Transactional)

One-liner for interviews: "A transaction ensures all-or-nothing execution — either every database operation in a unit of work commits together, or none of them do, leaving the system in a consistent state."

The Problem Transactions Solve

Imagine you're building a payment service for an e-commerce platform. A user clicks "Pay Rs.500". Your method does three things:

1. Deducts Rs.500 from the user's wallet
2. Creates an order record with status CONFIRMED
3. Sends a confirmation email via an external service

Here's what happens on a Friday evening deployment when the email service throws an exception after the wallet is already deducted:

Without a transaction: The wallet shows Rs.500 less, but there's no order. The user's money vanished into thin air. Your on-call gets paged at 2 AM on Saturday. You spend the weekend writing a reconciliation script.

With a transaction: The moment the email service throws, Spring rolls back the wallet deduction too. The user's balance is untouched. The system is exactly as it was before the method was called.

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph TX["@Transactional"]
        S1["1. Reserve Inventory<br/>(lock 2 units)"] --> S2["2. Create Order<br/>(status=PENDING)"]
        S2 --> S3["3. Payment Hold<br/>($149.99)"]
        S3 --> S4["4. Publish Event<br/>(OrderCreated)"]
    end

    S4 -->|"All succeed"| Commit["COMMIT"]
    S1 -->|"Any failure"| Rollback["ROLLBACK<br/>(inventory released,<br/>order deleted,<br/>hold cancelled)"]

    style TX fill:#ECFDF5,stroke:#6EE7B7,stroke-width:2px,color:#1E40AF
    style Commit fill:#ECFDF5,stroke:#6EE7B7,color:#1E40AF
    style Rollback fill:#FEE2E2,stroke:#FCA5A5,color:#1E40AF

How @Transactional Works Internally

What

@Transactional is a declarative way to wrap a method in a database transaction. Behind the scenes, Spring uses proxy-based AOP — it generates a wrapper class around your service that handles BEGIN, COMMIT, and ROLLBACK automatically.

Why

Without it, you'd write try-catch-finally blocks around every database operation, manually managing connections and transactions. That's error-prone and verbose.

When

Use @Transactional on any public method that performs database writes that must be atomic. Don't use it on private methods (it won't work) or on methods that only do external HTTP calls (you're holding a DB connection for no reason).

How: The Proxy Creation Process

Here's what actually happens when Spring starts up:

1. Spring scans your classes for @Transactional annotations during bean initialization.
2. A BeanPostProcessor (specifically InfrastructureAdvisorAutoProxyCreator) wraps the target bean in a proxy.
3. The proxy is either a JDK dynamic proxy (if the bean implements an interface) or a CGLIB subclass proxy (if no interface — this is the common case).
4. The proxy holds a reference to the TransactionInterceptor, which contains all the transaction management logic.

Here's what Spring generates behind the scenes (simplified CGLIB proxy):

public class TransferService$$EnhancerBySpringCGLIB extends TransferService {

    private TransactionInterceptor txInterceptor;
    private TransferService target;

    @Override
    public void transfer(Long fromId, Long toId, BigDecimal amount) {
        TransactionInfo txInfo = txInterceptor.createTransactionIfNecessary();
        try {
            target.transfer(fromId, toId, amount);  // your actual method
            txInterceptor.commitTransactionAfterReturning(txInfo);
        } catch (Throwable ex) {
            txInterceptor.completeTransactionAfterThrowing(txInfo, ex);
            throw ex;
        }
    }
}

Where This Fits

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
sequenceDiagram
    participant C as Controller
    participant P as Spring Proxy
    participant S as Your Service
    participant TM as TransactionManager
    participant DB as Database

    C->>P: call transfer()
    P->>TM: Begin transaction
    TM->>DB: START TRANSACTION
    P->>S: Execute your code
    S->>DB: INSERT / UPDATE / DELETE
    S->>P: Return (or throw)

    alt Success
        P->>TM: Commit
        TM->>DB: COMMIT
    else Exception
        P->>TM: Rollback
        TM->>DB: ROLLBACK
    end
    P->>C: Return result

Basic Usage (The Simple Version)

For 1-2 years of experience — this is all you need to start:

@Service
public class TransferService {

    @Transactional
    public void transfer(Long fromId, Long toId, BigDecimal amount) {
        Account from = accountRepository.findById(fromId).orElseThrow();
        Account to = accountRepository.findById(toId).orElseThrow();

        from.debit(amount);   // If this succeeds...
        to.credit(amount);    // ...but THIS throws an exception -> BOTH rolled back
    }
}

That's it. One annotation. Spring handles the rest. If anything throws a RuntimeException (unchecked), everything rolls back. If the method returns normally, everything commits.

@Transactional Properties — The Full Picture

@Transactional(
    propagation = Propagation.REQUIRED,      // Default — join or create
    isolation = Isolation.READ_COMMITTED,    // Default — see committed data only
    timeout = 30,                            // Seconds before timeout
    readOnly = false,                        // Optimization hint for reads
    rollbackFor = Exception.class,           // When to rollback
    noRollbackFor = BusinessWarning.class    // Don't rollback for this
)

Let's go deep on each one.

Propagation Types

What

Propagation defines how a @Transactional method behaves when it's called from within another transaction. Should it join the existing transaction? Start a new one? Run without any?

Why

Imagine your OrderService.placeOrder() calls AuditService.log(). If the audit logging fails, should the entire order be rolled back? Propagation gives you control over this decision.

When

• REQUIRED (default): 95% of the time. "I need a transaction. If one exists, I'll join it."
• REQUIRES_NEW: When the inner operation MUST commit independently. Audit logs, notifications.
• NESTED: When you want partial rollback within the same connection.
• NOT_SUPPORTED: External API calls that shouldn't hold a transaction.

How

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    M1(("methodA()")) -->|"@Transactional"| TX1{{"Transaction 1"}}
    TX1 --> M2[["methodB()"]]

    M2 -->|"REQUIRED"| J(["Joins TX1<br/>(same transaction)"])
    M2 -->|"REQUIRES_NEW"| N(["Suspends TX1<br/>Creates TX2"])
    M2 -->|"NESTED"| NS(["Savepoint in TX1<br/>(partial rollback)"])
    M2 -->|"NOT_SUPPORTED"| NO(["Suspends TX1<br/>Runs without TX"])

    style TX1 fill:#EFF6FF,stroke:#DBEAFE,stroke-width:2px,color:#1E40AF
    style J fill:#ECFDF5,stroke:#6EE7B7,color:#1E40AF
    style N fill:#FEF3C7,stroke:#FCD34D,color:#1E40AF

Production Scenario: Payment Fails — What Happens to the Order?

@Service
public class OrderService {
    @Transactional  // TX1 created here
    public void placeOrder(OrderRequest req) {
        orderRepo.save(new Order(req));        // part of TX1
        paymentService.charge(req.getAmount()); // joins TX1
    }
}

@Service
public class PaymentService {
    @Transactional(propagation = Propagation.REQUIRED)  // joins TX1
    public void charge(BigDecimal amount) {
        paymentRepo.save(new Payment(amount));
        throw new InsufficientFundsException(); // TX1 rolls back EVERYTHING
    }
}

@Service
public class OrderService {
    @Transactional  // TX1 created here
    public void placeOrder(OrderRequest req) {
        orderRepo.save(new Order(req));         // part of TX1
        try {
            paymentService.charge(req.getAmount()); // TX2 — completely independent
        } catch (PaymentException e) {
            orderRepo.updateStatus(req.getId(), PAYMENT_FAILED);
        }
    }
}

@Service
public class PaymentService {
    @Transactional(propagation = Propagation.REQUIRES_NEW)  // TX2 created
    public void charge(BigDecimal amount) {
        paymentRepo.save(new Payment(amount));
        throw new InsufficientFundsException(); // only TX2 rolls back
    }
}

@Service
public class OrderService {
    @Transactional  // TX1
    public void placeOrder(OrderRequest req) {
        orderRepo.save(new Order(req));
        try {
            paymentService.charge(req.getAmount()); // savepoint inside TX1
        } catch (PaymentException e) {
            // savepoint rolled back, but TX1 continues
            notificationService.sendPaymentFailedEmail(req);
        }
    }
}

@Service
public class PaymentService {
    @Transactional(propagation = Propagation.NESTED)  // savepoint in TX1
    public void charge(BigDecimal amount) {
        paymentRepo.save(new Payment(amount));
        throw new InsufficientFundsException(); // rolls back to savepoint only
    }
}

Going Deeper: REQUIRES_NEW + Audit Log

Here's a subtle bug that has bitten many production systems:

@Service
public class OrderService {

    @Transactional
    public void placeOrder(OrderRequest request) {
        Order order = orderRepository.save(new Order(request));
        paymentService.charge(order);  // If this fails, order rolls back

        // BUG: If audit throws, the order TX rolls back!
        auditService.log("ORDER_PLACED", order.getId());
    }
}

@Service
public class AuditService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void log(String action, Long entityId) {
        auditRepository.save(new AuditLog(action, entityId));
        // If this throws (DB full, constraint violation, etc.)
        // The exception propagates to OrderService and kills the order!
    }
}

The fix: Always wrap REQUIRES_NEW calls in try-catch when the caller's transaction matters more:

@Transactional
public void placeOrder(OrderRequest request) {
    Order order = orderRepository.save(new Order(request));
    paymentService.charge(order);

    // FIX: Audit failure should never kill the order
    try {
        auditService.log("ORDER_PLACED", order.getId());
    } catch (Exception e) {
        log.warn("Audit logging failed, order still committed", e);
    }
}

Staff-level insight: Use @TransactionalEventListener Instead

The cleanest pattern for "do something after the main TX commits" is an event listener. This decouples audit from the business logic entirely and guarantees the audit only fires after a successful commit.

@Service
public class OrderService {

    @Autowired private ApplicationEventPublisher eventPublisher;

    @Transactional
    public void placeOrder(OrderRequest request) {
        Order order = orderRepository.save(new Order(request));
        paymentService.charge(order);
        eventPublisher.publishEvent(new OrderPlacedEvent(order.getId()));
        // Event is held until commit — no risk to the main transaction
    }
}

@Component
public class AuditEventHandler {

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void onOrderPlaced(OrderPlacedEvent event) {
        auditRepository.save(new AuditLog("ORDER_PLACED", event.getOrderId()));
    }
}

Counter-questions an interviewer will ask:

• "When would NESTED deadlock but REQUIRES_NEW won't?" — NESTED uses the same connection, so no deadlock with itself. REQUIRES_NEW opens a second connection, which CAN deadlock if both try to lock the same row.
• "Why not always use REQUIRES_NEW?" — It opens a second database connection. With connection pool size 10 and 10 concurrent requests all using REQUIRES_NEW, you've doubled your connection demand to 20. Pool exhaustion.

The UnexpectedRollbackException Trap

What

UnexpectedRollbackException is thrown when Spring tries to commit a transaction that was already marked as "rollback-only" by an inner participant.

Why This Exists

When two methods share a transaction (REQUIRED propagation) and the inner method throws, the TransactionInterceptor around that inner method marks the shared transaction as rollback-only. Even if the outer method catches the exception, the transaction is permanently poisoned.

The "What Breaks" Story

You deploy on Thursday afternoon. Everything looks fine. Friday morning, the product team reports: "Orders with failed payments aren't getting the PAYMENT_FAILED status. They just... disappear."

You check the logs. You see your catch block executed. You see the log message "Payment failed, marking order as failed". But when you check the database — the order doesn't exist at all. Not with PAYMENT_FAILED status, not with any status.

What happened? The paymentService.charge() threw an InsufficientFundsException. Your catch block ran. But the transaction was already marked rollback-only. When your method returned, Spring tried to commit, found the rollback-only flag, and rolled back EVERYTHING — including the order creation AND the status update inside your catch block.

The Sequence of Doom

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
sequenceDiagram
    participant Outer as OrderService<br/>(TX owner)
    participant Inner as PaymentService<br/>(joins TX)
    participant TM as TransactionManager

    Outer->>Inner: charge() [joins TX1]
    Inner->>Inner: throw RuntimeException
    Note over Inner: TX1 marked rollback-only!
    Inner-->>Outer: exception propagates
    Outer->>Outer: catch(exception) — swallows it
    Outer->>TM: method returns normally, commit?
    TM->>TM: TX is rollback-only!
    TM-->>Outer: UnexpectedRollbackException!

Code That Triggers It

@Service
public class OrderService {

    @Transactional  // TX1 starts here
    public void placeOrder(OrderRequest req) {
        orderRepo.save(new Order(req));

        try {
            // PaymentService also has @Transactional(propagation = REQUIRED)
            // It JOINS TX1 — same physical transaction
            paymentService.charge(req.getAmount());
        } catch (InsufficientFundsException e) {
            // Developer thinks: "I caught it, so TX1 should be fine"
            log.warn("Payment failed, marking order as failed");
            orderRepo.updateStatus(req.getId(), PAYMENT_FAILED);
        }
        // When this method returns, Spring tries to COMMIT TX1
        // But TX1 was already marked rollback-only by paymentService!
        // BOOM: UnexpectedRollbackException
    }
}

@Service
public class PaymentService {

    @Transactional  // REQUIRED = joins TX1
    public void charge(BigDecimal amount) {
        if (balance.compareTo(amount) < 0) {
            throw new InsufficientFundsException(); // marks TX1 as rollback-only
        }
        paymentRepo.save(new Payment(amount));
    }
}

Why Catching the Exception Doesn't Help

Here's the timeline:

1. PaymentService.charge() throws InsufficientFundsException
2. The TransactionInterceptor AROUND charge() fires FIRST (before your catch)
3. The interceptor calls rollbackOn(InsufficientFundsException.class) — returns true (it's a RuntimeException)
4. The interceptor calls status.setRollbackOnly() on the shared transaction
5. NOW the exception propagates to your catch block
6. Your catch block runs — but the transaction is already poisoned
7. Your method returns normally
8. The outer TransactionInterceptor tries to commit
9. Finds rollbackOnly = true — throws UnexpectedRollbackException

The Fix: Three Approaches

@Service
public class PaymentService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)  // own TX
    public void charge(BigDecimal amount) {
        if (balance.compareTo(amount) < 0) {
            throw new InsufficientFundsException();
            // Only TX2 rolls back. TX1 is untouched.
        }
        paymentRepo.save(new Payment(amount));
    }
}

@Service
public class PaymentService {

    @Transactional(noRollbackFor = InsufficientFundsException.class)
    public void charge(BigDecimal amount) {
        if (balance.compareTo(amount) < 0) {
            throw new InsufficientFundsException();
            // TX NOT marked rollback-only because of noRollbackFor
        }
        paymentRepo.save(new Payment(amount));
    }
}

@Service
public class PaymentService {

    @Transactional
    public PaymentResult charge(BigDecimal amount) {
        if (balance.compareTo(amount) < 0) {
            return PaymentResult.insufficientFunds();
            // No exception -> no rollback marking
        }
        paymentRepo.save(new Payment(amount));
        return PaymentResult.success();
    }
}

// In OrderService:
PaymentResult result = paymentService.charge(amount);
if (!result.isSuccess()) {
    orderRepo.updateStatus(req.getId(), PAYMENT_FAILED);
}

Counter-questions an interviewer will ask:

• "How do you detect if your transaction is already marked rollback-only?" — Call TransactionAspectSupport.currentTransactionStatus().isRollbackOnly()
• "What's the actual exception message?" — "Transaction silently rolled back because it has been marked as rollback-only"
• "What happens to the data in the catch block?" — Everything in the catch block is ALSO rolled back, because it's all in the same poisoned transaction.

readOnly=true — What It Actually Does

What

readOnly = true is an optimization hint that tells Spring and Hibernate: "This method only reads data. Don't bother with dirty checking, flushing, or write detection."

Why

For a method that fetches 10,000 orders for a report, Hibernate normally takes a snapshot of every single entity (doubling memory usage), then at commit time compares each entity against its snapshot (O(n) CPU work). With readOnly = true, all of that is skipped. It's a significant performance win for read-heavy operations.

When

Use it on every method that doesn't modify data. getUser(), findOrders(), generateReport(). Don't use it on methods that create, update, or delete.

How — What Happens at Each Layer

@Transactional(readOnly = true)
public List<Order> getRecentOrders() {
    return orderRepository.findByCreatedAtAfter(LocalDateTime.now().minusDays(7));
}

Gotcha 1: Writing in a readOnly Transaction (Silent Data Loss)

Here's a scenario that has caused production incidents because it produces NO error:

@Transactional(readOnly = true)
public void generateReport() {
    List<Order> orders = orderRepo.findAll();

    // You modify an entity — what happens?
    orders.get(0).setStatus("ARCHIVED");

    // With Hibernate: FlushMode.MANUAL means no auto-flush
    // The change is SILENTLY LOST — no exception, no error, no log!

    // With PostgreSQL: if you force a flush, you get:
    // ERROR: cannot execute UPDATE in a read-only transaction
}

Gotcha 2: Native Queries Don't See In-Memory Changes

@Transactional(readOnly = true)
public ReportData generateReport() {
    // Step 1: Modify an entity in memory
    Order order = orderRepo.findById(1L).orElseThrow();
    order.setReportGenerated(true);  // pending change in persistence context

    // Step 2: Execute a native query
    List<Object[]> results = em.createNativeQuery(
        "SELECT * FROM orders WHERE report_generated = true"
    ).getResultList();

    // SURPRISE: The native query does NOT see the in-memory change!
    // Because FlushMode.MANUAL means Hibernate does NOT auto-flush
    // before native queries

    // results will NOT contain the order you just modified!
    return buildReport(results);
}

Gotcha 3: Which JDBC Drivers Actually Enforce readOnly

Counter-questions:

• "Can you write data in a readOnly transaction?" — Yes, in Hibernate the write is silently lost. In PostgreSQL with manual flush, you get an error. It depends on the driver.
• "Does readOnly help with read replicas?" — Yes, with AbstractRoutingDataSource, you can route readOnly transactions to a read replica.

Connection Acquisition Timing

What

This is about WHEN HikariCP actually gives your transaction a database connection from the pool. Spoiler: it's not when @Transactional fires.

Why It Matters

If you have a pool size of 10 and 10 concurrent requests, each holding a connection for 3 seconds (including an HTTP call to an external service), your pool is exhausted. Understanding when the connection is acquired and released is critical for pool sizing.

How It Works: Lazy Connection Acquisition

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
sequenceDiagram
    participant App as @Transactional Method
    participant TM as TransactionManager
    participant DS as HikariCP
    participant DB as Database

    App->>TM: Method enters (proxy intercepts)
    TM->>TM: Create TransactionStatus<br/>(logical TX started)
    Note over TM: NO connection borrowed yet!

    App->>App: Business logic (no DB calls)
    App->>App: First repository call
    App->>DS: getConnection()
    DS-->>App: Connection from pool
    App->>DB: SELECT / INSERT

    Note over App: Connection held until<br/>TX commit/rollback
    App->>TM: Method returns
    TM->>DB: COMMIT
    TM->>DS: releaseConnection()

With spring.jpa.open-in-view=false and default HibernateJpaDialect, the JDBC connection is acquired lazily — only when the first SQL statement actually executes. The logical transaction starts immediately, but the physical connection is borrowed on-demand.

Connection Holding Modes (Hibernate 5.2+)

The "What Breaks" Story: Connection Pool Exhaustion

You deploy a new feature: "Enrich orders with external logistics data." Here's the innocent-looking code:

@Transactional
public void processWithExternalCall(Long orderId) {
    Order order = orderRepo.findById(orderId).orElseThrow();
    // Connection borrowed here ^^^

    // External HTTP call — 3 seconds latency on average
    ExternalResult result = restTemplate.getForObject(url, ExternalResult.class);
    // Connection is HELD for 3 seconds doing absolutely nothing!

    order.setExternalRef(result.getRef());
    orderRepo.save(order);
    // Connection released at commit
}
// With pool size 10 and 10 concurrent requests, pool is EXHAUSTED.
// Thread 11 waits for a connection. After 30s, HikariCP throws:
// "Connection is not available, request timed out after 30000ms"

The fix: Move external calls outside the transaction:

public void processWithExternalCall(Long orderId) {
    // External call OUTSIDE transaction — no connection held
    ExternalResult result = restTemplate.getForObject(url, ExternalResult.class);

    // Short transaction — connection held only for the two DB ops
    updateOrder(orderId, result);
}

@Transactional
public void updateOrder(Long orderId, ExternalResult result) {
    Order order = orderRepo.findById(orderId).orElseThrow();
    order.setExternalRef(result.getRef());
    // Connection held for ~5ms, not 3 seconds
}

Transaction Timeouts

What

@Transactional(timeout = 5) tells Spring: "If this transaction takes more than 5 seconds, kill it."

How Spring Enforces It

@Transactional(timeout = 5)  // 5 seconds
public void longRunningMethod() {
    // Spring sets a deadline: now + 5 seconds
    // Every time Hibernate prepares a Statement, it calls:
    //   statement.setQueryTimeout(remainingSeconds)
    // If time expires mid-query, the DB driver throws SQLException
}

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph Timeout["Timeout Enforcement"]
        Start["TX starts<br/>deadline = now + 5s"] --> Q1["Query 1<br/>setQueryTimeout(5)"]
        Q1 -->|"2s elapsed"| Q2["Query 2<br/>setQueryTimeout(3)"]
        Q2 -->|"2s more"| Q3["Query 3<br/>setQueryTimeout(1)"]
        Q3 -->|"timeout!"| Ex["TransactionTimedOutException"]
    end

    style Start fill:#ECFDF5,stroke:#6EE7B7,color:#1E40AF
    style Q1 fill:#EFF6FF,stroke:#93C5FD,color:#1E40AF
    style Q2 fill:#FEF3C7,stroke:#FCD34D,color:#1E40AF
    style Q3 fill:#FEE2E2,stroke:#FCA5A5,color:#1E40AF
    style Ex fill:#FEE2E2,stroke:#FCA5A5,color:#991B1B

Gotcha: What Timeouts Do NOT Cover

This is the part that surprises people:

@Transactional(timeout = 5)
public void sneakyTimeout() {
    Order order = orderRepo.findById(1L).orElseThrow();  // 1s

    // Sleep for 10 seconds — NO timeout exception here!
    // Because timeout is only checked at next SQL statement
    Thread.sleep(10_000);

    // NOW when we try to execute the next SQL:
    order.setStatus("UPDATED");
    orderRepo.save(order);  // TransactionTimedOutException thrown HERE
}

Setting Global Defaults

spring:
  transaction:
    default-timeout: 30  # Global default: 30 seconds for all @Transactional methods

Isolation Levels

What

Isolation level defines how your transaction sees data that OTHER concurrent transactions are modifying. Think of it as "how paranoid should I be about other people's uncommitted work?"

Why

Without proper isolation, you get three categories of bugs:

1. Dirty Read — You read data someone else hasn't committed yet. They roll back. You have garbage.
2. Non-Repeatable Read — You read the same row twice in your transaction and get different values.
3. Phantom Read — You run the same query twice and get different row counts.

The Real Story: Financial Report Shows Wrong Numbers

You're generating a monthly financial report. Your code reads all orders, sums the totals. Meanwhile, someone is inserting new orders. Your first query says "52 orders, total Rs.1,50,000". Your second query (for breakdown by category) shows "54 orders" because two new orders were committed between your queries. Your report is internally inconsistent. The CFO is not happy.

Isolation Level Comparison

Dirty Read — Visualized

-- Transaction A (inserting a large order)
BEGIN;
UPDATE accounts SET balance = 200 WHERE id = 1;  -- was 1000
-- NOT YET COMMITTED (maybe they'll ROLLBACK!)

-- Transaction B (READ_UNCOMMITTED — can see uncommitted data)
SELECT balance FROM accounts WHERE id = 1;  -- reads 200 (DIRTY!)

-- Transaction A decides it was a mistake
ROLLBACK;  -- balance is back to 1000
-- Transaction B now has INVALID data (200) for a balance that's actually 1000

Non-Repeatable Read — Visualized

-- Transaction B (reads the same row twice)
BEGIN;
SELECT balance FROM accounts WHERE id = 1;  -- reads 1000

-- Transaction A sneaks in between
BEGIN;
UPDATE accounts SET balance = 500 WHERE id = 1;
COMMIT;  -- committed!

-- Transaction B reads again (same transaction, same query)
SELECT balance FROM accounts WHERE id = 1;  -- reads 500 (DIFFERENT!)
-- Your transaction saw two different values for the same row!
COMMIT;

When to Use Each Level

// Financial reports — must see a consistent snapshot of ALL data
@Transactional(isolation = Isolation.REPEATABLE_READ)
public FinancialReport generateMonthlyReport() { ... }

// Inventory reservation — cannot tolerate phantom rows appearing
@Transactional(isolation = Isolation.SERIALIZABLE)
public boolean reserveStock(Long productId, int qty) { ... }

// Dashboard stats — slight staleness is acceptable, speed matters
@Transactional(isolation = Isolation.READ_COMMITTED)
public DashboardStats getStats() { ... }

Rollback Rules — The Checked Exception Trap

What

By default, Spring only rolls back on unchecked exceptions (RuntimeException and its subclasses). Checked exceptions cause a COMMIT. Yes, you read that right.

The "What Breaks" Story

You write a file upload service. It saves metadata to the DB, then writes the file to disk. The disk write throws IOException (a checked exception). Spring commits the metadata even though the file wasn't written. Now you have a database record pointing to a file that doesn't exist.

// This COMMITS even though IOException is thrown!
@Transactional
public void uploadFile(MultipartFile file) throws IOException {
    FileMetadata meta = new FileMetadata(file.getName(), file.getSize());
    fileMetadataRepo.save(meta);  // This gets committed!

    Files.write(Path.of("/uploads/" + meta.getId()), file.getBytes());
    // IOException thrown here — but TX COMMITS because IOException is checked!
}

The Rules

The Fix

// FIXED: rollback on ALL exceptions
@Transactional(rollbackFor = Exception.class)
public void uploadFile(MultipartFile file) throws IOException {
    FileMetadata meta = new FileMetadata(file.getName(), file.getSize());
    fileMetadataRepo.save(meta);
    Files.write(Path.of("/uploads/" + meta.getId()), file.getBytes());
    // NOW if IOException is thrown, the metadata save is rolled back too
}

// Nuanced: rollback on everything EXCEPT business warnings
@Transactional(
    rollbackFor = Exception.class,
    noRollbackFor = BusinessWarningException.class
)
public void processOrder(OrderRequest req) throws Exception {
    // BusinessWarningException -> commit (it's just a warning)
    // Any other exception -> rollback
}

The Self-Invocation Problem

What

If a method within the same class calls another @Transactional method using this.method(), the transaction annotation is completely ignored. No transaction is created.

Why

Because this points to the real object, not the proxy. The proxy is what manages transactions. When you call this.saveOrder(), you're calling the method directly on the target object — the proxy never intercepts it.

The "What Breaks" Story

You deploy on Friday evening. Saturday morning, the on-call gets paged — wallets are deducted but orders aren't created. Here's why: the @Transactional on the private method doesn't work because Spring proxies only intercept public methods called from outside the bean.

@Service
public class OrderService {

    public void processOrder(Order order) {
        validate(order);
        saveOrder(order);  // @Transactional is IGNORED here!
    }

    @Transactional
    public void saveOrder(Order order) {
        orderRepository.save(order);
        // No transaction wrapping this call!
        // If an exception happens, partial data may be committed
    }
}

The Fix: Three Options

@Service
public class OrderService {

    @Lazy
    @Autowired
    private OrderService self;  // injects the PROXY, not this

    public void processOrder(Order order) {
        validate(order);
        self.saveOrder(order);  // goes through proxy — TX works!
    }

    @Transactional
    public void saveOrder(Order order) {
        orderRepository.save(order);
    }
}

@Service
public class OrderService {

    @Autowired
    private OrderPersistenceService persistenceService;

    public void processOrder(Order order) {
        validate(order);
        persistenceService.saveOrder(order);  // different bean = proxy call
    }
}

@Service
public class OrderPersistenceService {

    @Transactional
    public void saveOrder(Order order) {
        orderRepository.save(order);
    }
}

// In build.gradle or pom.xml, enable AspectJ compile-time weaving
// This modifies the bytecode directly — no proxy needed
@EnableTransactionManagement(mode = AdviceMode.ASPECTJ)
@Configuration
public class TxConfig { }

TransactionSynchronization Hooks

What

TransactionSynchronization lets you register callbacks on the transaction lifecycle — execute code before commit, after commit, or after completion (regardless of outcome).

Why

You need to send an email after an order is confirmed. But you can't send it inside the transaction — if the email sends but the transaction rolls back, the user got a confirmation for an order that doesn't exist. You need a hook that fires ONLY after the commit succeeds.

When

How

@Service
public class OrderService {

    @Transactional
    public Order placeOrder(OrderRequest req) {
        Order order = orderRepo.save(new Order(req));

        TransactionSynchronizationManager.registerSynchronization(
            new TransactionSynchronization() {

                @Override
                public void beforeCommit(boolean readOnly) {
                    // Last-chance validation — if this throws, TX rolls back!
                    validateInventoryStillAvailable(order);
                }

                @Override
                public void afterCommit() {
                    // Safe to send notifications — TX definitely committed
                    emailService.sendOrderConfirmation(order.getId());
                    messagingService.publishOrderCreatedEvent(order);
                }

                @Override
                public void afterCompletion(int status) {
                    if (status == STATUS_ROLLED_BACK) {
                        metricsService.incrementCounter("orders.failed");
                    }
                    // Clean up temp files regardless of outcome
                    tempFileService.cleanup(order.getTempFiles());
                }
            }
        );

        return order;
    }
}

afterCommit Pitfall: No Active Transaction

TransactionSynchronizationManager.registerSynchronization(
    new TransactionSynchronization() {
        @Override
        public void afterCommit() {
            // WARNING: There is NO active transaction here!
            // The original TX already committed.

            // This will run WITHOUT a transaction:
            orderRepo.save(auditRecord);  // may auto-commit each statement

            // If you need a new TX, you must create one explicitly:
            txTemplate.executeWithoutResult(status -> {
                auditRepo.save(new AuditRecord("ORDER_CREATED", orderId));
            });
        }
    }
);

Multi-DataSource Without JTA

What

When you need to write to two databases in a single operation but cannot (or don't want to) use JTA (XA transactions).

The Real Scenario

You have an Order DB and a Warehouse DB. When an order is placed, you need to create the order AND create a fulfillment record in the warehouse system. They're separate databases.

ChainedTransactionManager (Best-Effort 1PC)

@Configuration
public class MultiDataSourceConfig {

    @Bean
    public PlatformTransactionManager transactionManager(
            @Qualifier("primaryTxManager") PlatformTransactionManager primary,
            @Qualifier("secondaryTxManager") PlatformTransactionManager secondary) {
        // Commits in REVERSE order
        // If secondary commit fails AFTER primary committed -> inconsistency!
        return new ChainedTransactionManager(primary, secondary);
    }
}

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
sequenceDiagram
    participant App as Service Method
    participant CTM as ChainedTxManager
    participant TX1 as Primary TX
    participant TX2 as Secondary TX

    App->>CTM: begin()
    CTM->>TX1: begin()
    CTM->>TX2: begin()

    App->>App: Execute business logic

    App->>CTM: commit()
    CTM->>TX2: commit() [LAST resource commits FIRST]
    Note over TX2: If this fails, TX1 rolls back too
    CTM->>TX1: commit() [FIRST resource commits LAST]
    Note over TX1: If THIS fails, TX2 already committed!
    Note over CTM: Best-effort: not truly atomic

The Better Pattern: Outbox + Eventual Consistency

@Service
public class OrderFulfillmentService {

    @Transactional("primaryTxManager")
    public void createOrder(OrderRequest req) {
        Order order = orderRepo.save(new Order(req));
        // Write an outbox event in the SAME transaction as the order
        outboxRepo.save(new OutboxEvent("ORDER_CREATED", order.getId()));
        // Both writes succeed or fail together — atomic!
    }

    // Separate process polls outbox and writes to secondary DB
    @Scheduled(fixedDelay = 1000)
    @Transactional("secondaryTxManager")
    public void processOutbox() {
        List<OutboxEvent> events = outboxRepo.findUnprocessed();
        for (OutboxEvent event : events) {
            warehouseRepo.createFulfillment(event.getOrderId());
            event.markProcessed();
        }
    }
}

@TransactionalEventListener

What

A Spring event listener that only fires at specific points in the transaction lifecycle — most commonly, AFTER the transaction commits successfully.

Why

Regular @EventListener fires immediately when publishEvent() is called — still inside the transaction. If the transaction later rolls back, the event was already processed (email sent, Kafka message published). @TransactionalEventListener holds the event until the specified phase.

How

@Service
public class OrderService {

    @Autowired
    private ApplicationEventPublisher eventPublisher;

    @Transactional
    public Order placeOrder(OrderRequest req) {
        Order order = orderRepo.save(new Order(req));
        eventPublisher.publishEvent(new OrderPlacedEvent(order.getId()));
        return order;
        // Event is NOT delivered yet — waits for commit
    }
}

@Component
public class OrderEventHandler {

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void onOrderPlaced(OrderPlacedEvent event) {
        // This runs ONLY if the transaction committed successfully
        emailService.sendConfirmation(event.getOrderId());
        analyticsService.track("order_placed", event.getOrderId());
    }

    @TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
    public void onOrderFailed(OrderPlacedEvent event) {
        // Runs only if the transaction rolled back
        alertService.notifyTeam("Order creation failed: " + event.getOrderId());
    }
}

Programmatic Transactions with TransactionTemplate

When to Use

When @Transactional is too coarse-grained. Common scenarios:

• Processing a batch where each item needs its own transaction
• Conditional transaction logic ("start a TX only if X")
• Need different isolation/timeout per iteration

@Service
public class BatchProcessingService {

    private final TransactionTemplate txTemplate;

    public BatchProcessingService(PlatformTransactionManager txManager) {
        this.txTemplate = new TransactionTemplate(txManager);
        this.txTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);
        this.txTemplate.setTimeout(10);
    }

    public void processBatch(List<Item> items) {
        for (Item item : items) {
            // Each item in its own transaction — one failure doesn't kill the batch
            txTemplate.executeWithoutResult(status -> {
                try {
                    processItem(item);
                } catch (Exception e) {
                    status.setRollbackOnly();  // explicit rollback for this item only
                    logFailure(item, e);
                }
            });
        }
    }

    // With return value
    public Order createOrder(OrderRequest req) {
        return txTemplate.execute(status -> {
            Order order = orderRepo.save(new Order(req));
            if (order.getTotal().compareTo(BigDecimal.ZERO) <= 0) {
                status.setRollbackOnly();
                return null;
            }
            return order;
        });
    }
}

Distributed Transactions and the Saga Pattern

Why 2PC (Two-Phase Commit) Is Avoided in Microservices

JTA/XA coordinates transactions across multiple resources, but:

• Requires all participants to be available simultaneously (fragile)
• Holds locks across network calls — latency amplifies contention
• Single coordinator is a single point of failure
• Not supported by many cloud-native databases (DynamoDB, Cassandra)

Saga Pattern (What You Should Use Instead)

Instead of one distributed transaction, use a sequence of local transactions with compensating actions:

@Service
public class OrderSagaOrchestrator {

    public void placeOrder(OrderRequest req) {
        // Step 1: Create order (local TX)
        Order order = orderService.create(req);

        try {
            // Step 2: Charge payment (local TX via REST call)
            paymentService.charge(order);
        } catch (PaymentException e) {
            orderService.cancel(order);  // Compensating action
            throw e;
        }

        try {
            // Step 3: Reserve inventory (local TX via REST call)
            inventoryService.reserve(order);
        } catch (InventoryException e) {
            paymentService.refund(order);  // Compensate step 2
            orderService.cancel(order);    // Compensate step 1
            throw e;
        }
    }
}

Testing Transactions

Verify Rollback Actually Happened

@SpringBootTest
@Transactional  // Each test runs in a TX that rolls back after test
class OrderServiceTest {

    @Autowired private OrderService orderService;
    @Autowired private JdbcTemplate jdbc;

    @Test
    void transfer_insufficientFunds_rollsBackBothAccounts() {
        // Given
        jdbc.update("INSERT INTO accounts (id, balance) VALUES (1, 100)");
        jdbc.update("INSERT INTO accounts (id, balance) VALUES (2, 200)");

        // When
        assertThrows(InsufficientFundsException.class, () ->
            orderService.transfer(1L, 2L, BigDecimal.valueOf(500))
        );

        // Then — verify rollback
        BigDecimal balance1 = jdbc.queryForObject(
            "SELECT balance FROM accounts WHERE id = 1", BigDecimal.class);
        BigDecimal balance2 = jdbc.queryForObject(
            "SELECT balance FROM accounts WHERE id = 2", BigDecimal.class);

        assertThat(balance1).isEqualByComparingTo("100");  // unchanged
        assertThat(balance2).isEqualByComparingTo("200");  // unchanged
    }
}

Testing REQUIRES_NEW Commits Independently

@SpringBootTest
class AuditServiceTest {

    @Autowired private AuditService auditService;
    @Autowired private AuditRepository auditRepo;
    @Autowired private PlatformTransactionManager txManager;

    @Test
    void auditLog_persistsEvenWhenOuterTxRollsBack() {
        TransactionTemplate tx = new TransactionTemplate(txManager);

        try {
            tx.executeWithoutResult(status -> {
                auditService.log("TEST_ACTION", 123L);  // REQUIRES_NEW — commits independently
                status.setRollbackOnly();  // Force outer TX rollback
            });
        } catch (Exception ignored) {}

        // Audit log persisted despite outer rollback
        assertThat(auditRepo.findByAction("TEST_ACTION")).isNotEmpty();
    }
}

Transaction Managers

Spring abstracts transaction management behind the PlatformTransactionManager interface.

// Spring Boot auto-configures the right one.
// For JPA projects, JpaTransactionManager is auto-created.
// Manual config only needed for multi-datasource setups:
@Bean
public PlatformTransactionManager transactionManager(EntityManagerFactory emf) {
    return new JpaTransactionManager(emf);
}

Gotchas Summary — Quick Reference

Interview Questions