Locking and Concurrent Transaction Scheduling in GBase 8s Database (Part 1)
This article explores the transaction processing features of GBase 8s, revealing how it ensures ACID properties and effectively manages concurrent transactions.
Transaction Concepts and ACID Properties
Transaction
A transaction is a collection of operations in the database treated as a single unit, executed in an orderly manner without interference from other operations.
A transaction is a collection of operations on the database. This collection is an indivisible logical unit of work; all operations in the collection must either be fully executed or not executed at all during a single execution of the transaction.
Transaction Properties (ACID)
Atomicity
All operations within the transaction are either fully executed or not executed at all during the transaction's execution.
Consistency
The result of a transaction must maintain the database in a consistent state.
Isolation
All operations within a transaction are isolated from other transactions or operations. Concurrently executing transactions must not interfere with each other; the result of running a transaction alone should match the result when it runs concurrently with multiple other transactions.
Durability
Durability means that once a transaction has completed and been committed, the results of all its operations are permanently persisted in the database.
Scheduling of Concurrent Transactions
1. Concurrency Issues and Concurrent Operations
In practice, multiple transactions from different users often execute concurrently, leading to interleaving. This is known as the transaction concurrency problem.
Concurrent transactions can interfere with each other, disrupting normal execution, compromising ACID properties, and causing data errors.
Concurrent operations (Simultaneous Concurrency) are the database operations within concurrent transactions generated by multiple transactions running concurrently. The biggest issue they cause is database inconsistency.
Example
Two ticket outlets sell tickets for the same train on the same day simultaneously. The database transaction T1 executed by the first outlet is:
(1) Read the current remaining ticket count A, assume A=50;
(2) Sell one ticket, remaining count becomes A=A-1, i.e., A=49.
The database transaction T2 executed by the second outlet is:
(1) Read the current remaining ticket count A, assume A=50;
(2) Sell one ticket, remaining count becomes A=A-1, i.e., A=49.
Transactions T1 and T2 execute concurrently in the following order:
(1) Read the current remaining ticket count A, assume A=50;
(2) Read the current remaining ticket count A, assume A=50;
(3) Sell one ticket, remaining count becomes A=A-1, i.e., A=49;
(4) Sell one ticket, remaining count becomes A=A-1, i.e., A=49.
The transaction execution shows only one ticket sold, although two were actually sold. This could result in the same seat being sold twice, causing a data inconsistency error in the database.
Concurrent operations cause database inconsistency, as the following scenario illustrates. Transaction T1 modified the data object — the total number of tickets A — to 49, but Transaction T2 read A as 50 before T1's modification. T2 then modified A to 49 and wrote it back to the database, overwriting T1's change. As a result, A is now 49. After selling two tickets, the total should be 48, yet the database shows 49 — a clear data inconsistency error.
2. Scheduling
Scheduling refers to the order in which transactions are executed. When multiple transactions execute one after another, it is called a serial schedule. When they execute simultaneously, it is called a concurrent schedule.
3. Conflicts
A conflict occurs when two operations (reads or writes) in a transaction schedule, if their execution order is swapped, cause the result of the transactions to change.
Operations by different transactions on different data objects (whether reads or writes) do not conflict; nor do reads on the same data object by different transactions.
4. Locking
The primary technique for concurrency control is locking. Locking targets data objects in the database, such as tables, records, attributes, and indexes in a relational database. A data object is locked by requesting a lock from the system before the transaction performs operations on it.
After locking, transaction T gains control over the data object. No other transaction can perform any operations on this data object until T releases the lock.
Locking is a queuing mechanism that serializes parallel tasks by ordering them according to lock acquisition times, turning concurrent tasks into sequential ones.