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 )

Propagation	Behavior
REQUIRED	Join existing transaction or create a new one if none exists (default)
REQUIRES_NEW	Suspend current transaction and start a new one
NESTED	Execute within a nested transaction (supports rollback without affecting outer transaction)
SUPPORTS	Execute within current transaction if exists, otherwise non-transactional
NOT_SUPPORTED	Suspend current transaction, run non-transactional
MANDATORY	Must run inside existing transaction; throws exception if none
NEVER	Must not run inside a transaction; throws exception if exists

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:

Isolation Level	What It Means	Problems Prevented	Problems Allowed	Common Use Case
READ_UNCOMMITTED	Can read data that is not yet saved	None	Dirty Read, Non-Repeatable Read, Phantom Read	Rarely used, temporary or non-critical reports
READ_COMMITTED	Can read only saved (committed) data	Dirty Read	Non-Repeatable Read, Phantom Read	Most web applications, CRUD systems
REPEATABLE_READ	Same data stays the same inside one transaction	Dirty Read, Non-Repeatable Read	Phantom Read (DB-dependent)	Banking, inventory systems
SERIALIZABLE	Transactions run one by one	Dirty Read, Non-Repeatable Read, Phantom Read	None	Financial systems, critical operations

---

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