Spring Transaction Boundaries: Where to Commit and When to Split

Architecture

In Spring and JPA-based apps, the transaction often starts at the service layer. That is where the application has enough context to decide whether a set of writes belongs to one business action or several smaller units. If the transaction spans a network call, an external API, or poorly bounded domain logic, the database lock duration grows and the system becomes harder to reason about. Correct transaction design is therefore about boundaries: keep the database transaction narrow, make the business intent explicit, and avoid mixing domain orchestration with persistence concerns.

@Service
public class OrderService {
  private final OrderRepository repository;
  private final InventoryClient inventoryClient;

  @Transactional
  public void placeOrder(CreateOrderRequest request) {
    Order order = new Order(request.customerId(), request.items());
    repository.save(order);
    inventoryClient.reserve(request.items());
  }
}

@Entity
public class PaymentAttempt {
  @Id
  private String requestId;

  @Column(nullable = false)
  private String status;
}

javax.persistence.PessimisticLockException: could not obtain lock

at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.commit

DuplicatePaymentException: request already processed

at com.example.billing.PaymentFacade.submit(PaymentFacade.java:72)

The real boundary is the business action

A common trap in Spring applications is to put @Transactional on every repository or service method and assume the system is safe. That usually creates a confusing mix of short transactions, leaked locks, and database operations that are no longer aligned with the actual business requirement.

The strongest transaction plan starts by asking one question: what is the smallest unit of work that must stand as one consistent action for the user? That is the right boundary.

For a checkout flow, it might be the order and payment creation together. For a background data sync, it might be each batch item independently. The correct answer depends on the business outcome, not on the framework.

Why long transactions feel like a production bug

Spring makes transactions easy to attach, but it does not make them cheap. Long-lived transactions hold database locks for longer, increase contention, and can amplify latency under spikes. In a system with even moderate write pressure, a large transactional unit grows into a queue of blocked queries and noisy timeouts.

That is why the best Java design often separates:

1. fast, local state changes;
2. compensating or async follow-ups;
3. long-running orchestration that does not hold the DB transaction open.

A transaction should protect correctness, not hide an architecture problem.

Code patterns that help keep boundaries sane

The service layer is usually the right place for transactional logic because it embodies business intent. Repositories should mostly handle persistence operations. The service method should be explicit about when a unit of work is atomic and when it is not.

A good pattern is to keep the transaction small, invoke domain validation first, then persist the state that changes together. If there is an external side effect, decouple it through an outbox or event stream so the write path remains durable and auditable.

That is how you avoid the classic trap of mixing database writes, message publication, and API calls inside the same transaction and then wondering why your system is fragile under retries.

Idempotency is the second half of correctness

Even with a transaction, you still need idempotency. A user may retry a payment request, a message may be redelivered, or an upstream system may time out after the downstream service already processed the event. If the system is not designed for repeated execution, the database transaction does not solve the problem.

A strong Java application uses business-level keys, deduplication tables, or persisted request IDs to detect duplicate work. That turns retries into safe operations instead of silent data corruption.

Final guidance

For real Spring services, design the transaction boundary to match the business action, keep it short, and ensure idempotent retries. That combination gives you correctness without turning the app into a lock-contention machine.

If you can answer “what exactly must happen together, and what can happen later?” you are already on the right path.