Transactions

A transaction is a unit of work that is executed atomically, meaning either all operations succeed or none are applied. Spring provides a declarative and programmatic transaction management abstraction for Java applications.

What is a Transaction?

A transaction is a sequence of one or more database operations executed as a single unit of work.

It guarantees that:

• All operations complete successfully together, or
• None of them take effect

In simple words:

A transaction ensures multiple database operations are executed atomically using commit and rollback mechanisms, maintaining data integrity.

Example: Transferring money between accounts must debit one account and credit another atomically.

Why Transactions Are Important (ACID Properties)

1. Atomicity

• All operations in a transaction succeed or fail together
• Prevents partial data updates

Example: Bank Transfer

1. Debit ₹10,000 from Account A
2. Credit ₹10,000 to Account B

• If both steps succeed → COMMIT
• If credit fails after debit → ROLLBACK

2. Consistency

• Database moves from one valid state to another
• Ensures constraints and rules are maintained

Example: Order Placement

• Order total must be ≥ 0
• Product stock cannot be negative

Initial State:
Stock = 10

Transaction:
Order quantity = 3
New stock = 7

• Valid → COMMIT
• If stock becomes -1 → transaction fails

3. Isolation

• Controls visibility of uncommitted data between concurrent transactions
• Prevents:
  • Dirty Reads
  • Non-repeatable Reads
  • Phantom Reads

Example: Two Users Booking Last Ticket

Transaction T1: checks available seats → 1
Transaction T2: checks available seats → 1

Without isolation:

• Both book the seat (overbooking)

With isolation:

• One transaction completes first
• Other sees updated data and fails or waits

4. Durability

• Once committed, data is permanent
• Survives system crashes or restarts

Example: Payment Success

Payment marked as SUCCESS
Transaction committed
System crashes immediately

After restart:

Payment status is still SUCCESS

Durability ensures:

• Data survives crashes
• Logs and disk storage preserve committed changes

Spring Transaction Management

Spring provides declarative and programmatic transaction management.

1. Declarative Transactions

• Uses the @Transactional annotation.
• Simple, declarative approach without manual transaction code.

Example:

@Service
publicclassUserService {

@Autowired
private UserRepository userRepository;

@Transactional
publicvoidcreateUserAndOrders(User user, List<Order> orders) {
        userRepository.save(user);
        orders.forEach(orderRepository::save);
// All changes committed together
    }
}

Key Points:

• If any exception occurs, all changes are rolled back.
• Works with checked and unchecked exceptions (configurable).
• Can be applied on class or method level.

2. Programmatic Transactions

• Using TransactionTemplate or PlatformTransactionManager.
• Provides fine-grained control but more verbose.

Example:

transactionTemplate.execute(status -> {
    userRepository.save(user);
    orderRepository.save(order);
returnnull;
});

@Transactional Annotation

The @Transactional annotation is used to define transaction boundaries in Spring applications.

It tells Spring when to start, commit, or roll back a transaction automatically.

Spring manages transactions using AOP (proxy-based mechanism).

Where Can @Transactional Be Applied?

Method Level

• Only the annotated method runs within a transaction
• Most commonly used and recommended

Class Level

• All public methods of the class become transactional
• Method-level annotation overrides class-level configuration

Example

@Service
publicclassUserService {

@Transactional
publicvoidtransferMoney(Long fromId, Long toId, BigDecimal amount) {
        debitAccount(fromId, amount);
        creditAccount(toId, amount);
    }
}

Explanation:

• Transaction starts when transferMoney() begins
• If both operations succeed → COMMIT
• If any exception occurs → ROLLBACK
• Prevents partial updates and maintains consistency

Transaction Propagation

Propagation defines how transactions behave when calling another transactional method:

REQUIRED (Default Behavior)

REQUIRED means the method will use the existing transaction if one is already running.

If no transaction exists, Spring creates a new transaction.

Example:

Placing an order and saving order details.

@Transactional(propagation = Propagation.REQUIRED)
publicvoidsaveOrder() {
// joins existing transaction
}

• Most commonly used
• All operations succeed or fail together

REQUIRES_NEW

REQUIRES_NEW always starts a new transaction, even if another transaction already exists.

The existing transaction is temporarily suspended.

Example:

Saving audit logs while processing an order.

@Transactional(propagation = Propagation.REQUIRES_NEW)
publicvoidsaveAuditLog() {
// always runs in a new transaction
}

• Audit log is saved even if order fails
• Useful for logging and notifications

NESTED

NESTED creates a sub-transaction inside the main transaction using a savepoint.

If the nested transaction fails, it rolls back only its part, not the whole transaction.

Example:

Reserving inventory inside order processing.

@Transactional(propagation = Propagation.NESTED)
publicvoidreserveStock() {
// can rollback independently
}

• Partial rollback is possible
• Requires database support for savepoints

SUPPORTS

SUPPORTS runs inside a transaction if one exists.

If no transaction exists, it runs without a transaction.

Example:

Sending a notification.

@Transactional(propagation = Propagation.SUPPORTS)
publicvoidsendNotification() {
// transactional only if caller is transactional
}

• Flexible behavior
• No transaction overhead if not needed

NOT_SUPPORTED

NOT_SUPPORTED always runs without a transaction.

If a transaction exists, Spring suspends it.

Example:

Calling an external API.

@Transactional(propagation = Propagation.NOT_SUPPORTED)
publicvoidcallExternalService() {
// no transaction
}

• Prevents long-running external calls from blocking DB transactions

MANDATORY

MANDATORY requires an existing transaction.

If none exists, Spring throws an exception.

Example:

Security validation that must be transactional.

@Transactional(propagation = Propagation.MANDATORY)
publicvoidvalidateSecurity() {
// must run inside a transaction
}

• Ensures strict transactional control

NEVER

NEVER ensures the method must not run inside a transaction.

If a transaction exists, Spring throws an exception.

Example:

Health check or monitoring logic.

@Transactional(propagation = Propagation.NEVER)
publicvoidsystemHealthCheck() {
// no transaction allowed
}

• Used for non-business, system-level operations

Table ( Quick Revision )

Example :

@Service
public class OrderService {

    @Transactional(propagation = Propagation.REQUIRED)
    public void placeOrder(Order order) {

        securityService.validate(order);        // MANDATORY
        orderRepository.save(order);            // REQUIRED

        inventoryService.reserveStock(order);  // NESTED
        paymentService.process(order);          // REQUIRED

        auditService.logAction(order);          // REQUIRES_NEW
        notificationService.notify(order);      // SUPPORTS
        shippingService.ship(order);            // NOT_SUPPORTED
        monitoringService.healthCheck();        // NEVER
    }
}

Transaction Isolation Levels

Isolation defines how concurrent transactions interact:

Rollback and Exceptions

• By default, @Transactional rolls back on unchecked exceptions (RuntimeException, Error)
• To roll back on checked exceptions, specify:

@Transactional(rollbackFor = Exception.class)
publicvoidprocessPayment() { ... }

• Commit occurs if method completes without exception

Transaction Read-Only Mode

Marking a transaction as read-only can optimize performance for read queries:

@Transactional(readOnly = true)
public List<User>findAllActiveUsers() { ... }

• Avoids unnecessary locks or flushes in some databases

Nested Transactions and Savepoints

• Spring supports nested transactions using JDBC savepoints
• Only works if the underlying database supports savepoints
• Useful for partial rollback within a larger transaction

Example:

• Main transaction starts → savepoint created
• Inner operation fails → rollback to savepoint
• Main transaction continues → other operations succeed

Best Practices

• Keep transactions short-lived to avoid locks and contention
• Avoid calling self-invoking methods with @Transactional (Spring proxy limitation)
• Use service layer for transaction boundaries, not repositories
• For read-heavy operations, consider readOnly=true
• Combine propagation and isolation carefully depending on concurrency needs

Conclusion

• Transactions ensure data integrity with ACID properties
• Spring provides declarative (@Transactional) and programmatic transaction management
• Propagation controls nested or dependent transaction behavior
• Isolation levels control concurrency and visibility of uncommitted data
• Proper usage avoids data corruption, deadlocks, and inconsistent states