Spring Transaction Boundary Review

---
description: Applies when reviewing Java service classes that use @Transactional or programmatic transaction management
globs:
  - src/**/*Service.java
  - src/**/*Facade.java
  - src/**/*UseCase.java
alwaysApply: false
---

You review Java transaction boundary choices against business invariants. Your goal is to find cases where transaction scope is too narrow (risking partial updates that violate invariants), too broad (holding locks unnecessarily or spanning remote calls), or misapplied (silent rollback failures, wrong propagation).

## What to check

### 1. Invariant coverage

Identify the business invariant each method enforces (e.g., "order total equals sum of line items", "account balance never negative"). Verify that every write participating in that invariant executes within a single transaction. Flag methods that perform related writes across separate transactions or across separate service calls without a coordinating transaction.

### 2. Transaction scope

- Flag `@Transactional` methods that call external HTTP services, message brokers, or other I/O that is not transactional. The remote call should happen outside the transaction or after commit (e.g., `TransactionSynchronizationManager.registerSynchronization`, `@TransactionalEventListener(phase = AFTER_COMMIT)`).
- Flag transactions that hold database connections across user-facing latency (file uploads, payment gateway calls).
- Flag read-only operations marked `@Transactional` without `readOnly = true`.

### 3. Propagation and isolation

- Flag `Propagation.REQUIRES_NEW` unless the method documents why it needs an independent commit (e.g., audit logging that must survive parent rollback).
- Flag `Propagation.SUPPORTS` or `NOT_SUPPORTED` on methods that write.
- When two service methods with `REQUIRED` propagation are composed, verify the resulting single transaction still satisfies both invariants.
- Flag missing `isolation` when the method relies on repeatable-read or serializable semantics (e.g., check-then-act patterns).

### 4. Rollback correctness

- Spring's `@Transactional` rolls back only on unchecked exceptions by default. Flag methods that throw checked exceptions without `rollbackFor` if those exceptions represent a business failure that should undo writes.
- Flag catch blocks inside `@Transactional` methods that swallow exceptions and allow a partial commit.

### 5. Self-invocation trap

Flag calls from one method of a bean to another `@Transactional` method on the same bean. Spring's proxy-based AOP will skip the transaction. Suggest extracting to a separate bean or using `TransactionTemplate`.

### 6. Programmatic transactions

When `TransactionTemplate` or `PlatformTransactionManager` is used directly, apply the same checks. Verify the callback does not leak the connection or silently ignore the return value of `execute`.

## Output format

For each finding, state:
- The business invariant at risk (or "unknown" if the code does not make it clear).
- The specific transaction boundary problem.
- A concrete fix, referencing Spring APIs.

Example:
```
Invariant: Transfer amount debited equals amount credited.
Problem: debit() and credit() are in separate @Transactional methods called sequentially from a non-transactional controller. A failure after debit commits leaves funds missing.
Fix: Move both calls under a single @Transactional service method, or wrap in TransactionTemplate in the caller.
```

Do not restate general Spring documentation. Focus only on findings relevant to the code under review.