1. Fundamental Transaction Concepts

A transaction represents a single logical unit of work that accesses and potentially modifies various data items within a database.

Transactions serve as the foundational unit for database recovery and concurrency control. They must exhibit four key properties, commonly referred to as ACID:

Atomicity: A transaction constitutes a logical unit of work for the database, operating as an indivisible unit. All modifications within a transaction are either entirely executed or not executed at all.

Consistency: Upon completion, a transaction must leave the database in a consistent state. All database rules must be applied to the modifications within the transaction, preserving data integrity throughout the process. For instance, in a fund transfer between two accounts, the combined balance remains constant.

Isolation: The execution of one transaction cannot be interfered with by other concurrent transactions.

Durability: Once a transaction is committed, its operations are permanently persisted in the database. The committed transaction's effects survive even in the event of system failures.

2. Underlying Transaction Mechanism

Spring's transaction management fundamentally relies on the database's native transaction support. Without database transaction capabilities, Spring cannot provide transaction functionality.

The mechanism for Spring transaction management (using annotations as an example):

The configuration file enables annotation-driven transaction management. Classes and methods are marked witth the @Transactional annotation.

During Spring's startup phase, annotated classes and methods are parsed and proxy objects are generated. The framework examines the @Transactional parameters and injects the appropriate transaction configuration. The proxy handles transaction operations—committing on normal execution and rolling back upon exceptions.

Actual database-level transaction commits and rollbacks are accomplished through binary logs or redo logs.

3. Transaction Propagation Behaviors in Spring

Constant	Description
PROPAGATION_REQUIRED	Supports the current transaction. If no transaction exists, creates a new one. This is Spring's default propagation behavior.
PROPAGATION_REQUIRES_NEW	Creates a new transaction. If a current transaction exists, it is suspended.
PROPAGATION_SUPPORTS	Supports the current transaction. If no transaction exists, executes without transaction context.
PROPAGATION_MANDATORY	Supports the current transaction. Throws an exception if no transaction exists.
PROPAGATION_NOT_SUPPORTS	Executes without transaction context. Suspends the current transaction if one exists.
PROPAGATION_NEVER	Executes without transaction context. Throws an exception if a transaction exists.
PROPAGATION_NESTED	Executes within a nested transaction if a transaction exists in the context. Creates a new transaction otherwise. Only works with DataSourceTransactionManager.

4. Database Isolation Levels

Isolation Level	Value	Potential Issues
Read-Uncommitted	0	Prone to dirty reads
Read-Committed	1	Prevents dirty reads; allows non-repeatable reads and phantom reads
Repeatable-Read	2	Prevents dirty reads and non-repeatable reads; allows phantom reads
Serializable	3	Full isolation. Transactions execute sequentially, preventing dirty reads, non-repeatable reads, and phantom reads. Performance impact is significant; use with caution.

Dirty Read: One transaction modifies data but has not yet committed. Another transaction can read this uncommitted data. If the first transaction rolls back, the second transaction has read invalid data.

Non-repeatable Read: Within a single transaction, two read operations occur. Between these reads, another transaction modifies the data, causing inconsistent results.

Phantom Read: The first transaction reads a range of data. The second transaction inserts new rows within this range. The first transaction then attempts to modify these rows but finds the newly inserted ones it didn't see before.

Higher isolation levels provide stronger data integrity and consistency guarantees but at the cost of reduced concurrency and performance.

Most databases default to Read-Committed isolation, including SQL Server and Oracle.

Some databases default to Repeatable-Read, such as MySQL with the InnoDB storage engine.

5. Isolation Levels in Spring

Constant	Description
ISOLATION_DEFAULT	Uses the database's default isolation level. MySQL uses REPEATABLE_READ by default, while Oracle uses READ_COMMITTED.
ISOLATION_READ_UNCOMMITTED	The lowest isolation level. Allows reading of uncommitted changes. May result in dirty reads, phantom reads, or non-repeatable reads.
ISOLATION_READ_COMMITTED	Allows reading of committed data from concurrent transactions. Prevents dirty reads but phantom reads and non-repeatable reads remain possible.
ISOLATION_REPEATABLE_READ	Ensures consistent results for multiple reads of the same field unless modified by the current transaction. Prevents dirty reads and non-repeatable reads but phantom reads may still occur.
ISOLATION_SERIALIZABLE	The highest isolation level. Fully compliant with ACID properties. Transactions execute sequentially, preventing all anomalies. However, this causes significant performance degradation and is rarely used in practice.

6. Transaction Nesting Scenarios

AccountService {

    void transferFunds() {
        PaymentService.processPayment();
    }

}

PaymentService {

    void processPayment() {
    }

}

Scenario A: PaymentService.processPayment() uses PROPAGATION_REQUIRED

1. If AccountService.transferFunds() has an active transaction, calling PaymentService.processPayment() shares the same transaction. Any exception causes both transactions to roll back together as a unified unit.

2. If AccountService.transferFunds() has no transaction, PaymentService.processPayment() creates its own transaction. AccountService.transferFunds() operates without transaction scope. An exception in PaymentService.processPayment() does not trigger a rollback in AccountService.transferFunds().

Scenario B: PaymentService.processPayment() uses PROPAGATION_REQUIRES_NEW

Calling PaymentService.processPayment() suspends AccountService.transferFunds()'s transaction. PaymentService.processPayment() executes within a new independent transaction.

1. If PaymentService.processPayment() commits successfully, but AccountService.transferFunds() subsequently fails, PaymentService.processPayment()'s changes remain committed and do not roll back.

2. If PaymentService.processPayment() fails and the exception is caught and handled by AccountService.transferFunds(), the outer transaction may still commit. If the exception propagates unhandled, the outer transaction rolls back.

Scenario C: PaymentService.processPayment() uses PROPAGATION_NESTED

Calling PaymentService.processPayment() suspends AccountService.transferFunds()'s transaction. PaymentService.processPayment() starts a nested sub-transaction with a savepoint.

1. If PaymentService.processPayment() commits, but AccountService.transferFunds() fails, both transactions roll back.

2. If PaymentService.processPayment() fails and the exception is caught by AccountService.transferFunds(), the outer transaction may still commit. If the exception propagates unhandled, the outer transaction rolls back.

7. Spring Transaction API Architecture

Spring offers two primary working modes:

• JdbcTemplate: A modern approach introduced in Spring 2.5 that handles database metadata more effectively.
• RDBMS Object: A query design pattern similar to JDO (Java Data Objects).

Regardless of the chosen mode, you can intermix approaches within your code to leverage their respective advantages.

The main template implementations include:

• JdbcTemplate: The core template class for JDBC operations.
• NamedParameterJdbcTemplate: Wraps JdbcTemplate to provide named parameter support instead of traditional JDBC positional placeholders ("?"). Requires JDK 1.4 or higher.
• SimpleJdbcTemplate: Combines the most frequently used features of both JdbcTemplate and NamedParameterJdbcTemplate. Leverages Java 5 features like generics, varargs, and autoboxing for a simplified API. Requires Java 5 or higher.
• SimpleJdbcInsert and SimpleJdbcCall: Typically used alongside SimpleJdbcTemplate. Require JDK 5 or higher and sufficient database metadata availability.

Exception Handling

Configuration Module

JdbcTemplate

DataSource

Spring obtains database connections through DataSource, which is part of the JDBC specification and uses ConnectionFactory to acquire connections. Containers and frameworks can abstract connection pooling and transaction management from application code.

When using Spring's JDBC layer, you can obtain DataSource through JNDI or configure a third-party connection pool implementation. Popular third-party implementations include Apache Commons DBCP and c3p0.

Note: DriverManagerDataSource is intended for testing purposes only. It lacks connection pooling functionality, resulting in poor performance when multiple requests require connections.

Object Module

JdbcTemplate is the core class within the core package.

Advantages:

It handles resource creation and cleanup automatically, significantly simplifying JDBC usage.

Using JdbcTemplate requires implementing callback interfaces following a well-defined contract.

You can instantiate JdbcTemplate within a DAO implementation by passing a DataSource reference. Alternatively, you can configure JdbcTemplate as a bean in Spring's IOC container and inject it into DAO implementations. The DataSource should always be configured as a bean in the Spring IOC container. In the first approach, the DataSource bean is past to the service. In the second approach, the DataSource bean is passed to the JdbcTemplate bean.

NamedParameterJdbcTemplate

This template wraps JdbcTemplate to provide convenient named parameter support instead of traditional JDBC positional placeholders ("?").

Distributed Transactions

Distributed System Characteristics (CAP Theorem)

Data Consistency Models

Strong Consistency: After an update operation completes, any subsequent access from any process or thread returns the updated value. While user-friendly, this model sacrifices availability.

Weak Consistency: The system does not guarantee that subsequent accesses will return the most recent updated value.

Eventual Consistency: A specific form of weak consistency. The system guarantees that without subsequent updates, it will eventually return the last updated value. In the absence of failures, the inconsistency window duration depends primarily on communication delays, system load, and the number of replica copies. DNS systems exemplify eventual consistency.