1 Definition and core concepts
A transaction is a sequence of operations treated as one logical unit of work. In computing, the term is used most often in database systems and distributed applications, where a transaction groups related changes so that they succeed or fail together. This model helps maintain consistency when multiple reads and writes must be coordinated.
Transactions are central to dependable system design because they provide a controlled way to update data, recover from errors, and avoid partial changes that could leave a system in an invalid state. They are commonly discussed in relation to properties such as atomicity, consistency, isolation, and durability.
1.1 Transaction as a unit of work
As a unit of work, a transaction may include one or many operations. These operations are treated as a single logical action from the perspective of the system. For example, transferring money between two accounts may require one withdrawal and one deposit, but the transaction is considered complete only when both steps are handled together.
This approach makes it easier to reason about system behavior. Rather than managing each operation separately, the application or database engine can rely on the transaction boundary to define when changes become permanent.
1.2 Commit and rollback
A commit finalizes a transaction and makes its changes durable. Once committed, the results are generally preserved even if the system later fails. A rollback reverses the effects of a transaction that has not been committed, restoring the prior state.
These two actions are the main outcomes of transaction processing. Commit is used when all required steps succeed, while rollback is used when an error, conflict, or interruption prevents completion.
1.3 State transitions
A transaction usually moves through a sequence of states during its lifetime. These states reflect whether the work is still in progress, ready to be finalized, or already completed. State transitions are important because they guide recovery and concurrency control mechanisms.
1.3.1 Active state
In the active state, the transaction is executing its operations. It may read data, write changes, or wait for resources. During this stage, the transaction is not yet complete and its effects are typically not permanent.
1.3.2 Partially committed state
A transaction reaches the partially committed state after its final operation has executed but before the system has fully secured the result. At this point, the system has accepted the transaction logic, but durability may still depend on logging or other safeguards.
1.3.3 Committed and aborted states
A committed transaction has completed successfully, and its changes are now part of the permanent state of the system. An aborted transaction has been stopped before completion, and its effects are removed or ignored. Abortion may occur because of a failure, a conflict, or an explicit cancellation.
2 Transaction properties
Transaction properties define the guarantees a system provides while processing work. These properties are often summarized by the acronym ACID, which is widely used in database theory and practice. Together, they describe how transactions preserve correctness under failure and concurrent access.
2.1 Atomicity
Atomicity means that a transaction is all or nothing. Every operation inside the transaction must complete successfully, or none of them should take effect. This prevents partial updates from being left behind after an error.
2.2 Consistency
Consistency means that a transaction should move the system from one valid state to another valid state. The exact rules depend on the application and data model, but the transaction should not violate integrity constraints, business rules, or structural requirements.
2.3 Isolation
Isolation means that concurrent transactions should not interfere with one another in a way that produces incorrect results. Each transaction should behave as though it is running alone, even when several are executing at the same time.
2.3.1 Isolation levels
Isolation levels describe how strongly a system separates concurrent transactions. Stronger levels reduce the chance of anomalies but may lower performance. Weaker levels can improve throughput while allowing more visible interaction between transactions.
2.3.2 Read phenomena
Read phenomena are effects that can occur when one transaction reads data affected by another transaction. Common examples include dirty reads, nonrepeatable reads, and phantom reads. These phenomena help explain the practical differences between isolation levels.
2.4 Durability
Durability means that once a transaction is committed, its results should survive crashes, power loss, or other failures. Systems usually achieve this by writing transaction records to stable storage and using recovery procedures after restart.
3 Transaction processing in databases
Database systems use transaction processing to coordinate changes safely and efficiently. The database engine tracks changes, manages concurrent activity, and provides mechanisms for recovery if a failure occurs. These functions are often tightly integrated with storage and logging subsystems.
3.1 Transaction logs
A transaction log records changes made by transactions in a durable sequence. Logs are used to reconstruct committed work and, when necessary, undo incomplete work. They are a key part of recovery because they provide a historical record of operations.
3.2 Concurrency control
Concurrency control coordinates access when multiple transactions operate at the same time. Its purpose is to prevent conflicts that could corrupt data or produce inconsistent results. Different methods balance correctness, simplicity, and performance in different ways.
3.2.1 Lock-based methods
Lock-based methods use shared and exclusive locks to regulate access to data items. A transaction may need to wait until another transaction releases a conflicting lock. This approach is widely used because it is straightforward and effective.
3.2.2 Timestamp ordering
Timestamp ordering assigns each transaction a logical time value and uses that ordering to decide which operations may proceed. Conflicting actions are arranged according to their timestamps, helping ensure a serializable outcome without relying primarily on locks.
3.2.3 Optimistic concurrency control
Optimistic concurrency control assumes conflicts are uncommon. Transactions proceed without heavy restriction and are checked near the end to see whether their changes conflict with others. If a conflict is detected, the transaction may be retried.
3.3 Recovery mechanisms
Recovery mechanisms restore the database to a correct state after a failure. They rely on logs, stored metadata, and restart procedures to determine which changes should be preserved and which should be reversed.
3.3.1 Undo and redo
Undo removes the effects of transactions that did not complete successfully. Redo reapplies committed changes that may not yet have reached permanent storage at the time of failure. Many recovery systems use both operations together.
3.3.2 Checkpointing
Checkpointing records a stable point in the transaction log and the database state. By marking such points, the system can reduce the amount of log data that must be examined during recovery, which shortens restart time.
4 Types of transactions
Transactions appear in several forms depending on the size of the operation and the environment in which it runs. The main distinctions concern how many statements are involved, whether transactions are nested, and whether multiple systems participate.
4.1 Single-statement transactions
A single-statement transaction consists of one database statement that is executed as an atomic unit. Many systems treat such statements as transactions automatically, even if the user does not explicitly define a transaction block.
4.2 Multi-statement transactions
A multi-statement transaction contains several operations grouped together. This format is common when a sequence of reads and writes must succeed as one coordinated action, such as creating an order and updating inventory in the same logical step.
4.3 Nested transactions
Nested transactions are transactions inside other transactions. The inner transaction may be treated as a subunit whose success contributes to the larger transaction. This structure is useful in complex applications that need modular control over groups of operations.
4.4 Distributed transactions
Distributed transactions span more than one database, service, or node. They are used when a single logical action affects multiple systems and the results must remain coordinated. Because several participants are involved, distributed transactions are more complex to manage and recover.
5 Transaction management
Transaction management covers the commands, components, and programming practices used to start, control, and end transactions. It helps ensure that application logic aligns with the guarantees offered by the database or middleware layer.
5.1 Transaction managers
A transaction manager coordinates transaction boundaries and tracks their status. It may be part of the database engine, an application server, or a separate middleware component. In distributed environments, it often communicates with multiple resource managers.
5.2 Begin, commit, and rollback commands
Begin starts a new transaction, commit finalizes it, and rollback cancels it. These commands define the most basic transaction lifecycle and are commonly exposed in database languages and application frameworks.
5.3 Savepoints
Savepoints allow a transaction to mark intermediate positions that can be revisited during rollback. If an error occurs, the system can return to a savepoint rather than undoing the entire transaction. This provides finer control in long or complex workflows.
5.4 Error handling
Error handling determines how a system responds when a transaction cannot continue. Typical responses include retrying the operation, rolling back to a savepoint, aborting the transaction, or reporting the failure to the caller. Good error handling reduces the chance of inconsistent outcomes.
6 Distributed transaction processing
Distributed transaction processing coordinates work across multiple systems that may not share a single storage engine. It is designed to preserve correctness when a transaction spans different networked participants, each of which may fail independently.
6.1 Two-phase commit protocol
The two-phase commit protocol is a coordination method used to help distributed transactions reach a consistent final decision. In the first phase, participants report whether they can commit. In the second phase, the coordinator instructs them to commit or roll back based on the collected responses.
6.2 One-phase commit
One-phase commit is a simpler approach used when only one participant is involved or when coordination requirements are limited. It avoids some of the overhead of distributed coordination, but it provides fewer safeguards across multiple systems.
6.3 Failure handling
Failure handling addresses problems such as network loss, participant crashes, and coordinator failure. Distributed systems often need logging, retry logic, and recovery procedures to determine the final state of a transaction after interruption.
6.4 Coordination across services
Coordination across services ensures that each participant applies changes in a compatible way. This may involve shared transaction managers, messaging systems, or application-level protocols. The main goal is to prevent partial completion across services.
7 Transactions in software applications
Application software often relies on transactions to make higher-level operations reliable. Developers use transaction support to protect data integrity, simplify error handling, and coordinate interactions with external components.
7.1 Database transactions in application code
Application code typically begins a transaction before performing related data updates and commits it after all steps succeed. If a problem occurs, the application can roll back the transaction to discard incomplete work. This pattern is common in business software, web applications, and service backends.
7.2 Transactional middleware
Transactional middleware provides transaction services between applications and data sources. It may manage transaction boundaries, coordinate resources, and integrate with application frameworks. Such middleware is especially useful when several components must share the same transactional context.
7.3 Transactional messaging
Transactional messaging links message delivery with transactional state changes. The aim is to ensure that a message is sent only if the associated work is committed, or that message processing is reversed if the transaction fails. This supports reliable integration between systems.
7.4 Idempotency and retries
Idempotency means that repeating an operation has the same effect as performing it once. It is valuable in transaction-heavy systems because retries may occur after timeouts or network errors. When operations are idempotent, repeated attempts are less likely to create duplicate effects.
8 Performance and design considerations
Transaction systems must balance correctness with speed and scalability. Stronger guarantees often require more coordination, which can increase overhead. Designers therefore consider workload patterns, contention levels, and recovery requirements when choosing transaction strategies.
8.1 Contention and locking overhead
Contention occurs when multiple transactions compete for the same data or resources. Locking can protect correctness, but it may also create waiting time and reduce concurrency. High contention is often a major limiting factor in transaction throughput.
8.2 Throughput and latency trade-offs
Throughput refers to the number of transactions a system can process over time, while latency is the time required for one transaction to finish. Techniques that improve isolation or durability may increase latency, whereas lighter coordination may allow more throughput.
8.3 Deadlocks
A deadlock happens when transactions wait on one another in a cycle, so none can proceed. Database systems detect or prevent deadlocks using wait tracking, timeouts, or lock ordering rules. When a deadlock is resolved, at least one transaction is usually rolled back.
8.4 Scalability strategies
Scalability strategies aim to keep transaction systems responsive as workload grows. Common approaches include reducing transaction scope, partitioning data, using optimistic methods where suitable, and limiting cross-system coordination. The best strategy depends on the application’s consistency requirements and access patterns.