Transaction Management - Detailed Class Notes
1. ACID Properties
In database systems, a transaction is a single logical unit of work that may consist of one or more
operations like insert, update, delete, or read. To ensure correctness and reliability of data, every
transaction must satisfy the ACID properties. These are:
Atomicity: Atomicity means that either the entire transaction is executed successfully or none of its
operations are executed at all. If any part of the transaction fails, the whole transaction fails and the
database is restored to its original state before the transaction began. For example, in a banking
transaction of transferring money from Account A to Account B, if the debit from A succeeds but
credit to B fails, then the whole transaction should be rolled back.
Consistency: Consistency ensures that a transaction brings the database from one valid state to
another valid state. It maintains database rules such as integrity constraints, triggers, and
cascades. For example, if there is a constraint that the balance in an account should not fall below
zero, then after any transaction, this rule must still hold true.
Isolation: Isolation ensures that the execution of one transaction is independent of others. Even if
multiple transactions run concurrently, the result should be the same as if they had executed
sequentially. For example, if two people book the last seat in a train at the same time, isolation
ensures that only one transaction will succeed and the database remains correct.
Durability: Durability means that once a transaction has been committed, its changes are
permanent, even in the event of a system crash or power failure. For example, once money has
been transferred from Account A to Account B and the transaction is committed, the update must
remain in the system no matter what happens afterward.
2. Transactions and Schedules
A transaction is a sequence of database operations that are executed as a single logical unit of
work. It may involve multiple steps such as inserting, updating, or deleting records.
Schedules: A schedule is the order in which the operations of different transactions are executed.
There are two types of schedules:
- Serial Schedule: All operations of one transaction are executed before starting another
transaction. This ensures correctness but reduces concurrency.
- Non-Serial Schedule: Operations of multiple transactions are interleaved. This increases
concurrency but may lead to issues like inconsistent data if not controlled properly.
Example:
Suppose we have two transactions:
T1: Read(A), A = A – 100, Write(A)
T2: Read(A), A = A * 1.1, Write(A)
- In a serial schedule (T1 followed by T2), final value of A will differ compared to the order where T2
executes before T1.
- If interleaved without control, results may become unpredictable due to conflicts between reads
and writes.
3. Concurrent Execution of Transactions
Concurrency means executing multiple transactions at the same time to improve system
performance and resource utilization. However, concurrent execution may lead to problems such
as:
- Dirty Read: A transaction reads data written by another transaction that has not yet been
committed. If the other transaction fails, the first transaction has read invalid data.
- Lost Update: Two transactions update the same data at the same time and one update gets lost.
- Uncommitted Dependency: A transaction depends on a value from another transaction that is
later rolled back.
- Inconsistent Retrievals: A transaction reads different parts of the database at different times,
getting inconsistent data.
Example:
If Transaction T1 updates Account A while Transaction T2 is reading the same account at the same
time, T2 may read a value that is not yet committed or may miss the update. Proper concurrency
control mechanisms are required to avoid such issues.
