Spring Boot Transaction Management - Comprehensive

Notes
1. Introduction to Transactions in Spring Boot

What are Transactions?

Definition: A transaction is a sequence of database operations that are treated as a single unit
of work

Purpose: Ensures data integrity and consistency in database operations

Spring Boot Integration: Provides seamless integration with Hibernate/JPA through
declarative transaction management

Why Use Spring Transactions?

Simplified Management: No need for manual transaction handling with Hibernate
Declarative Approach: Use annotations instead of programmatic transaction code

Automatic Rollback: Handles exceptions and rollbacks automatically

Connection Management: Manages database connections efficiently

2. @Transactional Annotation

Basic Usage
Primary Annotation: @Transactional is the main annotation for transaction management

Declarative Style: Eliminates boilerplate transaction management code

Automatic Proxy Creation: Spring creates proxies to handle transaction lifecycle

How @Transactional Works Internally

java

// Spring wraps your method with transaction management code

createTransactionIfNecessary();
try {
yourMethod(); // Your actual business logic
commitTransactionAfterReturning();
} catch (Exception exception) {
rollbackTransactionAfterThrowing();
throw exception;
}
Application Levels (Priority Order - Lowest to Highest)
1. Interface Level: Applied to entire interface
2. Superclass Level: Applied to parent class

3. Class Level: Applied to entire class

4. Interface Method Level: Applied to specific interface method

5. Superclass Method Level: Applied to parent class method

6. Method Level: Applied to specific method (Highest Priority)

Example Implementation

java

@Transactional(readOnly = true) // Class level - default read-only

public class EmployeeService {

@Autowired
private EmployeeRepository employeeRepo;

@Transactional // Method level - overrides class level settings

public Employee addEmployee(Employee employee) {
Employee savedEmployee = employeeRepo.save(employee);
// Additional operations within same transaction
return savedEmployee;
}
}

3. ACID Properties of Transactions

A - Atomicity
All or Nothing Principle: Either all operations succeed or all fail

Complete Execution: All operations within transaction are executed successfully

Rollback Capability: If any operation fails, entire transaction is rolled back

Data Integrity: Prevents partial updates that could corrupt data

C - Consistency
State Transition: Moves database from one consistent state to another
Constraint Validation: All database constraints must be satisfied

Business Rules: Ensures business logic rules are maintained

Data Validity: Modified data passes all validation checks
I - Isolation

Transaction Separation: Changes are invisible to other transactions until commit

Concurrent Access: Multiple transactions can run simultaneously without interference

Data Protection: Prevents dirty reads and inconsistent data access

Isolation Levels: Different levels control visibility of uncommitted changes

D - Durability
Persistent Storage: Committed changes are permanently saved
System Failure Recovery: Data survives system crashes and restarts

Storage Guarantee: Changes are written to non-volatile storage

Long-term Reliability: Data remains intact over time

4. Transaction Propagation Types

REQUIRED (Default)
Behavior: Join existing transaction or create new one

Usage: Most common propagation type

Characteristics:
Checks for active transaction

Creates new transaction if none exists

Joins existing transaction if available

Exception rolls back entire transaction (parent + child)

java

@Transactional(propagation = Propagation.REQUIRED)
public void methodWithRequired() {
// Business logic here
}

REQUIRES_NEW
Behavior: Always create a completely new transaction

Usage: When you need independent transaction handling

Characteristics:
Suspends current transaction if exists

Creates new physical transaction with new database connection

 Outer transaction resumes after inner completes
Independent rollback behavior

java

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void methodWithRequiresNew() {
// Runs in completely separate transaction
}

NESTED
Behavior: Uses savepoints for nested operations

Usage: When you need partial rollback capability

Characteristics:
Creates savepoint if transaction exists

Rollback only to savepoint on exception

Works like REQUIRED if no active transaction

Allows partial transaction recovery

java

@Transactional(propagation = Propagation.NESTED)
public void methodWithNested() {
// Can rollback to savepoint if needed
}

MANDATORY
Behavior: Requires existing transaction, throws exception if none
Usage: When method must run within existing transaction context

Characteristics:
Never creates new transaction

Throws exception if no active transaction

Joins existing transaction

Rollback affects entire transaction chain

 java

@Transactional(propagation = Propagation.MANDATORY)
public void methodWithMandatory() {
// Must be called within existing transaction
}

NEVER
Behavior: Throws exception if transaction exists

Usage: When method must run outside transaction context

Characteristics:
Prohibits transaction execution

Throws IllegalTransactionStateException if transaction exists

Internal methods can still create transactions

Useful for read-only operations that don't need transactions

java

@Transactional(propagation = Propagation.NEVER)
public void methodWithNever() {
// Must run without any transaction
}

NOT_SUPPORTED
Behavior: Suspends existing transaction and runs without transaction

Usage: When you need to temporarily escape transaction context

Characteristics:
Suspends current transaction if exists

Executes without transaction

Resumes original transaction after completion

Useful for operations that shouldn't be part of transaction

java

@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void methodWithNotSupported() {
// Runs outside transaction context
}

SUPPORTS
 Behavior: Flexible - works with or without transaction
Usage: When transaction is optional

Characteristics:
Joins existing transaction if available
Runs without transaction if none exists

Most flexible propagation type

Adapts to calling context

java

@Transactional(propagation = Propagation.SUPPORTS)
public void methodWithSupports() {
// Works in any context
}

5. Transaction Isolation Levels

Overview
Purpose: Control degree of isolation between concurrent transactions
Trade-off: Balance between consistency and performance

Configuration: Set via @Transactional(isolation = Isolation.LEVEL)

Read Phenomena

Dirty Read

Definition: Reading uncommitted data from another transaction

Problem: Data might be rolled back, making read invalid

Example: T1 modifies data, T2 reads it, T1 rolls back

Risk: Working with data that never officially existed

Non-Repeatable Read

Definition: Same query returns different results within same transaction

Problem: Data changes between reads in same transaction

Example: T1 reads data, T2 modifies and commits, T1 reads again with different result

Risk: Inconsistent data within single transaction

Phantom Read

Definition: Same query returns different number of rows

 Problem: New rows appear/disappear between reads
Example: T1 counts records, T2 inserts new record, T1 counts again with different total

Risk: Set-based operations become unreliable

Isolation Levels

READ_UNCOMMITTED

Allows: All read phenomena (Dirty, Non-repeatable, Phantom)

Performance: Highest

Consistency: Lowest

Use Case: When performance is critical and consistency is less important

READ_COMMITTED (Default in most databases)

Prevents: Dirty reads

Allows: Non-repeatable reads, Phantom reads

Performance: High
Consistency: Moderate

Use Case: Most common business applications

REPEATABLE_READ

Prevents: Dirty reads, Non-repeatable reads

Allows: Phantom reads

Performance: Moderate

Consistency: High
Use Case: When consistent reads are important

SERIALIZABLE

Prevents: All read phenomena

Allows: None
Performance: Lowest

Consistency: Highest
Use Case: Critical financial or audit operations

6. @Transactional Rules and Best Practices

Method Requirements
 Visibility: Must be applied only to public methods

Invocation: Method must be called from outside the bean (external invocation)

Proxy Limitation: Internal method calls bypass proxy and ignore @Transactional

Self-Invocation: Calling @Transactional method from same class won't work

Best Practices
1. Service Layer: Apply transactions at service layer, not repository layer
2. Method Granularity: Keep transactional methods focused and small

3. Exception Handling: Be aware of checked vs unchecked exception rollback behavior

4. Read-Only Optimization: Use readOnly = true for query-only operations

5. Timeout Settings: Set appropriate timeout values for long-running operations

6. Isolation Selection: Choose appropriate isolation level based on business needs

Common Configuration Options

java

@Transactional(
propagation = Propagation.REQUIRED,
isolation = Isolation.READ_COMMITTED,
timeout = 30,
readOnly = false,
rollbackFor = {Exception.class},
noRollbackFor = {BusinessException.class}
)

Performance Considerations
Connection Pooling: Transactions hold database connections
Lock Duration: Longer transactions increase lock contention

Resource Usage: Consider memory and CPU impact

Batch Operations: Use appropriate batch sizes for bulk operations

7. Advanced Transaction Concepts

Rollback Behavior
Default: Rollback on unchecked exceptions (RuntimeException and Error)
Checked Exceptions: Do not trigger rollback by default

Custom Configuration: Use rollbackFor and noRollbackFor attributes

 Manual Rollback: Use TransactionStatus.setRollbackOnly()

Transaction Synchronization
Before Commit: Execute code before transaction commits

After Commit: Execute code after successful commit

After Rollback: Execute code after rollback

Use Cases: Cache invalidation, event publishing, cleanup operations

Testing Transactions
@Transactional in Tests: Automatically rolls back after each test
@Rollback: Control rollback behavior in tests

@Commit: Force commit in test methods

Test Isolation: Ensure tests don't interfere with each other

8. Common Pitfalls and Troubleshooting

Common Issues
1. Self-Invocation: Internal method calls bypass transaction proxy
2. Private Methods: @Transactional ignored on non-public methods

3. Exception Handling: Catching exceptions prevents rollback

4. Connection Leaks: Long-running transactions can exhaust connection pool

5. Deadlocks: Poor transaction design can cause database deadlocks

Debugging Tips
Enable Transaction Logging: Set appropriate log levels
Monitor Connection Pool: Watch for connection exhaustion

Profile Performance: Identify slow transactions

Test Rollback Scenarios: Verify exception handling works correctly

Monitoring and Metrics

Transaction Duration: Monitor transaction execution time

Rollback Frequency: Track rollback rates

Connection Usage: Monitor database connection utilization

Lock Contention: Identify database locking issues