Jakarta Transactions — JTA

What is JTA — and Why Does It Exist?

A transaction is a sequence of operations that the database treats as a single, indivisible unit of work. All the operations succeed and are made permanent together (commit), or all are undone (rollback) — there is no in-between. The classic example is a bank transfer: debit one account and credit another. If the debit succeeds but the credit fails halfway through, the money has vanished. Without transactional semantics, that is exactly what happens.

JTA (Jakarta Transactions API) is the Jakarta EE specification that provides a vendor-neutral interface for controlling transactions in a managed runtime — the same interface works whether the transaction manager is from WildFly, WebSphere, or Payara. Its core interfaces are UserTransaction (for manual control) and TransactionManager (used internally by the container). Most application code never calls these directly — instead it relies on @TransactionAttribute (EJB) or @Transactional (CDI) to declare transaction semantics declaratively.

/*
 * The problem JTA solves — without it, two separate JDBC connections
 * have no shared fate: if the second INSERT fails, the first stays committed.
 */
// WITHOUT transactions (dangerous):
connection1.prepareStatement("UPDATE accounts SET balance = balance - ? WHERE id = ?")
           .executeUpdate();   // debit committed immediately
connection2.prepareStatement("UPDATE accounts SET balance = balance + ? WHERE id = ?")
           .executeUpdate();   // if this throws, debit is already permanent → money gone

// WITH @Transactional (correct):
@Transactional
public void transfer(Long fromId, Long toId, BigDecimal amount) {
    accountRepo.debit(fromId, amount);    // both participate in the same transaction
    accountRepo.credit(toId, amount);     // exception here rolls back the debit too
}                                          // normal return → both committed atomically

ACID Properties — What Each Actually Guarantees

ACID is widely recited and just as widely misunderstood. Each property is guaranteed by a different part of the database engine, and knowing what each one does (and does not) cover helps you reason about failure modes.

Container-Managed vs Bean-Managed Transactions

CMT — Container-Managed Transactions (always prefer this)

The container starts, commits, and rolls back the transaction on your behalf based on annotations. You declare what you want; the runtime figures out how. This is the correct default for virtually all application code.

import jakarta.ejb.Stateless;
import jakarta.ejb.TransactionAttribute;
import jakarta.ejb.TransactionAttributeType;

@Stateless
public class BankService {

    @PersistenceContext
    private EntityManager em;

    // REQUIRED is the default — no annotation needed, but explicit is clearer
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void transfer(Long fromId, Long toId, BigDecimal amount) {
        Account from = em.find(Account.class, fromId);
        Account to   = em.find(Account.class, toId);

        if (from.getBalance().compareTo(amount) < 0) {
            throw new InsufficientFundsException(fromId, amount);
            // RuntimeException → container rolls back the transaction automatically
        }
        from.debit(amount);   // dirty-checked by JPA — no em.update() needed
        to.credit(amount);
        // method returns normally → container commits
    }
}

BMT — Bean-Managed Transactions (use only when you genuinely need it)

BMT gives you full programmatic control: you call userTransaction.begin(), commit(), and rollback() yourself. This is necessary when you need fine-grained control that CMT cannot express — for example, committing inside a loop to avoid holding a transaction open across thousands of records, or checking the rollback status before deciding whether to proceed.

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class BatchImportService {

    @Resource
    private UserTransaction utx;

    @PersistenceContext
    private EntityManager em;

    public void importInChunks(List<Record> records) throws Exception {
        int chunkSize = 500;
        for (int i = 0; i < records.size(); i += chunkSize) {
            List<Record> chunk = records.subList(i,
                Math.min(i + chunkSize, records.size()));
            utx.begin();
            try {
                chunk.forEach(em::persist);
                em.flush();
                utx.commit();     // commit every 500 rows — short transactions, less lock pressure
            } catch (Exception e) {
                utx.rollback();   // only this chunk is rolled back, not the whole import
                throw e;
            }
        }
    }
}

Transaction Propagation — @TransactionAttribute and @Transactional

Every EJB method and every CDI bean method annotated with @Transactional carries a propagation type that defines what happens to the transaction when the method is called. The two annotation systems express the same six types with slightly different syntax:

// EJB (on @Stateless / @Stateful / @Singleton beans)
@TransactionAttribute(TransactionAttributeType.REQUIRED)

// CDI (on @ApplicationScoped / @RequestScoped / any CDI-managed bean)
import jakarta.transaction.Transactional;
import jakarta.transaction.Transactional.TxType;
@Transactional(TxType.REQUIRED)

Propagation in practice — audit logging

@ApplicationScoped
public class AuditService {

    @PersistenceContext
    private EntityManager em;

    // REQUIRES_NEW: this commits in its own transaction regardless of
    // whether the caller's transaction later rolls back.
    @Transactional(TxType.REQUIRES_NEW)
    public void log(String user, String action, String outcome) {
        em.persist(new AuditEntry(user, action, outcome, Instant.now()));
    }
}

@ApplicationScoped
public class TransferService {

    @Inject private AccountRepository accounts;
    @Inject private AuditService audit;

    @Transactional
    public void transfer(Long fromId, Long toId, BigDecimal amount) {
        audit.log("system", "TRANSFER_ATTEMPT", fromId + "→" + toId);
        // AuditEntry committed immediately in its own tx.

        accounts.debit(fromId, amount);
        accounts.credit(toId, amount);
        // This tx commits or rolls back — the audit entry is already permanent either way.
    }
}

Rollback Rules — The Checked Exception Trap

This is the most common silent bug in transactional Jakarta EE code.

By default, @Transactional and CMT both roll back the transaction when the method exits via a RuntimeException (unchecked). A checked exception — one that extends Exception but not RuntimeException — does not trigger a rollback by default. The transaction commits even though an exception was thrown.

@Transactional
public void processPayment(Order order) throws PaymentGatewayException {
    em.persist(order);             // order persisted
    gateway.charge(order);         // throws PaymentGatewayException (checked)
    // Exception propagates up, but the transaction COMMITS.
    // The order row exists in the database with no corresponding payment.
    // Silent data inconsistency.
}

// THE FIX: declare rollbackOn for checked exceptions
@Transactional(rollbackOn = PaymentGatewayException.class)
public void processPayment(Order order) throws PaymentGatewayException {
    em.persist(order);
    gateway.charge(order);  // now rolls back the transaction if this throws
}

// Or wrap in a RuntimeException to get automatic rollback
@Transactional
public void processPayment(Order order) {
    em.persist(order);
    try {
        gateway.charge(order);
    } catch (PaymentGatewayException e) {
        throw new PaymentFailedException("Gateway rejected payment", e);
        // PaymentFailedException extends RuntimeException → rollback triggered
    }
}

@Transactional
public void dangerousPattern(Order order) {
    em.persist(order);
    try {
        gateway.charge(order);
    } catch (Exception e) {
        log.error("Payment failed", e);
        // Swallowed exception — method returns normally — transaction COMMITS.
        // Order is in the database, payment was never taken.
    }
}

Self-invocation — the proxy bypass trap

// BROKEN: calling a @Transactional method from within the same class
@ApplicationScoped
public class OrderService {

    @Transactional
    public void placeOrder(OrderRequest req) {
        createOrder(req);     // direct 'this' call — bypasses the CDI proxy
        reserveInventory(req); // @Transactional on this method is silently ignored
    }

    @Transactional(TxType.REQUIRES_NEW)
    public void reserveInventory(OrderRequest req) {
        // This was supposed to run in a new transaction. It doesn't.
        // It runs in placeOrder's transaction — or no transaction if placeOrder
        // wasn't called from outside either.
    }
}

// FIX OPTION 1: Inject self via CDI (self-injection goes through the proxy)
@ApplicationScoped
public class OrderService {

    @Inject
    private OrderService self;   // CDI-managed proxy of this bean

    @Transactional
    public void placeOrder(OrderRequest req) {
        self.reserveInventory(req);   // through proxy → new transaction correctly started
    }

    @Transactional(TxType.REQUIRES_NEW)
    public void reserveInventory(OrderRequest req) { ... }
}

// FIX OPTION 2 (cleaner): Extract reserveInventory into a separate CDI bean.
// Two beans calling each other always go through proxies.

Isolation Levels — What Problems Each One Solves

Isolation controls how much one transaction can see of another's in-progress changes. More isolation means fewer data anomalies but more locking and lower throughput. Understanding which anomalies each level prevents is essential for tuning concurrent applications.

/*
 * The three anomalies, concretely:
 *
 * DIRTY READ: Transaction A reads a row that Transaction B modified but hasn't
 *   committed yet. B rolls back. A is operating on data that never existed.
 *
 * NON-REPEATABLE READ: Transaction A reads row #42. Transaction B updates and
 *   commits row #42. Transaction A reads row #42 again. Gets a different value.
 *   Same query, different result within the same transaction.
 *
 * PHANTOM READ: Transaction A queries "SELECT * FROM orders WHERE total > 100".
 *   Transaction B inserts a new order with total = 150 and commits.
 *   Transaction A runs the same query again. Gets an extra row that wasn't there.
 *   Same query, different set of rows within the same transaction.
 */

// JPA: set isolation level on the EntityManager factory (persistence.xml)
// or programmatically via JDBC connection unwrap (Hibernate-specific):
import org.hibernate.Session;

Session session = em.unwrap(Session.class);
session.doWork(conn ->
    conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE));

Flush vs Commit — What Each One Actually Does

This distinction trips up developers who are new to JPA. They are not the same operation.

@Transactional
public void createProductAndLog(Product product) {
    em.persist(product);
    // At this point: product exists in the persistence context (first-level cache).
    // The database has NOT seen it yet. product.getId() may be null (SEQUENCE strategy
    // will pre-assign the ID; IDENTITY strategy requires the INSERT to get it).

    em.flush();
    // NOW: Hibernate writes the SQL INSERT to the database within the current
    // transaction. The row is visible to other queries in this same transaction.
    // product.getId() is now populated even with IDENTITY strategy.
    // The transaction is still open — other transactions cannot see this row yet.

    auditLog.record(product.getId(), "CREATED");
    // method returns normally → container COMMITS.
    // Now the INSERT is permanent and visible to all other transactions.
}

/*
 * Rule of thumb:
 * - em.flush() = "write changes to the database, still within the transaction"
 * - Commit = "make changes permanent and release all locks"
 *
 * Premature flush = unnecessary round-trips to the database.
 * Missing flush when you need the generated ID = product.getId() is null.
 */

XA Transactions — Spanning Multiple Resources

An XA transaction coordinates a single atomic unit of work across multiple independent transactional resources — two databases, a database and a JMS queue, a database and a message broker. If any resource fails to commit, all are rolled back.

// XA requires XA-capable JDBC drivers and a JTA-compatible connection pool
// (e.g. Agroal with XA datasources on WildFly, or Atomikos in standalone)

@Stateless
public class OrderFulfillmentService {

    @PersistenceContext(unitName = "ordersDB")
    private EntityManager ordersEm;

    @PersistenceContext(unitName = "inventoryDB")
    private EntityManager inventoryEm;

    @Inject
    @JMSConnectionFactory("java:/jms/XAConnectionFactory")
    private JMSContext jms;

    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void fulfillOrder(Order order) {
        ordersEm.persist(order);                         // write to orders DB

        InventoryItem item = inventoryEm.find(
            InventoryItem.class, order.getItemId());
        item.decreaseStock(order.getQuantity());          // write to inventory DB

        jms.createProducer().send(
            jms.createQueue("shipping"),
            "SHIP:" + order.getId());                       // enqueue JMS message

        // All three resources commit atomically via 2PC, or all roll back.
    }
}

Two-Phase Commit — how XA achieves atomicity

/*
 * Phase 1 — PREPARE:
 *   Transaction Manager asks every resource manager: "Can you commit?"
 *   Each resource manager writes to its own write-ahead log and votes YES or NO.
 *   A vote of NO from any single resource means the whole transaction will abort.
 *
 * Phase 2 — COMMIT (or ROLLBACK):
 *   If ALL resource managers voted YES: TM sends COMMIT to each.
 *   If ANY resource manager voted NO:   TM sends ROLLBACK to all.
 *
 * The window between Phase 1 and Phase 2 is the "in-doubt" window —
 * if the TM crashes here, some resources may have committed and some not.
 * Proper JTA transaction managers (Narayana on WildFly, etc.) write their
 * own recovery log so they can resolve in-doubt transactions on restart.
 * This is why rolling your own XA coordinator is a terrible idea.
 */

The Saga Pattern — Transactions Without XA in Distributed Systems

Microservices cannot share a JTA transaction manager across service boundaries — each service has its own database and its own transaction scope. XA does not work here. The Saga pattern replaces a single distributed transaction with a sequence of local transactions, each of which publishes an event or message. If any step fails, preceding steps are undone via compensating transactions.

There are two coordination styles: choreography (each service reacts to events from the previous step, no central orchestrator) and orchestration (a dedicated saga orchestrator tells each service what to do and handles failures). Orchestration is easier to reason about and to observe.

// Orchestration-style saga: one class drives all steps and compensations
@ApplicationScoped
public class PlaceOrderSaga {

    @Inject private OrderService     orderService;
    @Inject private PaymentService   paymentService;
    @Inject private InventoryService inventoryService;

    public void execute(OrderRequest req) {
        String orderId    = null;
        String paymentId  = null;
        String reservationId = null;

        try {
            // Each step commits its own local transaction independently
            orderId       = orderService.create(req);                      // step 1
            paymentId     = paymentService.charge(req.getPayment());       // step 2
            reservationId = inventoryService.reserve(req.getItems());      // step 3
            orderService.confirm(orderId);                                 // step 4

        } catch (Exception e) {
            // Compensate in reverse order — each compensation is its own local tx
            if (reservationId != null) inventoryService.release(reservationId);
            if (paymentId     != null) paymentService.refund(paymentId);
            if (orderId       != null) orderService.cancel(orderId);
            throw new OrderFailedException("Saga rolled back: " + e.getMessage(), e);
        }
    }
}

Best Practices and Common Pitfalls

Interview Questions