Unit-4 - Chapter 10 - Concurrency Control Techniques
Unit-4 - Chapter 10 - Concurrency Control Techniques
Unit-4 - Chapter 10 - Concurrency Control Techniques
1. Locking data items to prevent multiple transactions from accessing the items
concurrently; a number of locking protocols have been proposed.
2. Use of timestamps. A timestamp is a unique identifier for each transaction, generated
by the system.
3. Multiversion concurrency control protocols that use multiple versions of a data
item.
4. Optimistic Concurrency Control: based on the concept of validation or certification
of a transaction after it executes its operations; these are sometimes called optimistic
protocols.
A lock is a variable associated with a data item that describes the status of the item with
respect to possible operations that can be applied to it. Generally, there is one lock for
each data item in the database.
Types of Locks:
• Binary locks: only two states of a lock; too simple and too restrictive; not used in
ractice.
• Shared/exclusive locks: which provide more general locking capabilities and are
used in practical database locking schemes. (Read Lock as a shared lock, Write
Lock as an exclusive lock).
• Certify lock: used to improve performance of locking protocols.
• Intension Locks: used for locking data items of multiple granularities.
Binary locks
• A binary lock can have two states or values: locked and unlocked (or 1 and 0,
for simplicity).
• A binary lock enforces mutual exclusion on the data item; i.e., at a time only one
transaction can hold a lock.
• A distinct lock is associated with each database item X. If the value of the lock on
X is 1, item X cannot be accessed by a database operation that requests the item.
If the value of the lock on X is 0, the item can be accessed when requested.
• LOCK(X) : indicates the current value (or state) of the lock associated with item
X
Conversion of Locks
UPGRADING:
If T is the only transaction holding a read lock on X at the time it issues the
write_lock(X) operation, the lock can be upgraded; otherwise, the transaction must wait.
DOWNGRADING:
It is also possible for a transaction T to issue a write_lock(X) and then later on to
downgrade the lock by issuing a read_lock(X) operation.
Example:
Claims:
The 2PL protocol guarantees serializability
• Any schedule of transactions that follow 2PL will be serializable
• We therefore do not need to test a schedule for serializability
But, it may limit the amount of concurrency since transactions may have to hold onto
locks longer than needed, creating the new problem of deadlocks.
• Conservative 2PL (Or Static 2PL): Requires a transaction to lock all the items it
accesses before the transaction begins execution, by predeclaring it’s read-set and
write-set.(the read-set of a transaction is the set of all items that the transaction
reads, and the write-set is the set of all items that it writes.) If any of the
predeclared items needed cannot be locked, the transaction does not lock any
item; instead, it waits until all the items are available for locking.
POLICY - Lock all that you need before reading or writing. Transaction is in
shrinking phase after it starts.
• Strict 2PL: The most popular variation of 2PL is strict 2PL, which guarantees
strict schedules. In this variation, a transaction T does not release any of its
exclusive (write) locks until after it commits or aborts. Hence, no other
transaction can read or write an item that is written by T unless T has committed,
leading to a strict schedule for recoverability.
• Rigorous 2PL: A transaction T does not release any of its locks (exclusive or
shared) until after it commits or aborts Behaves similar to Strict 2 PL except it is
more restrictive, but easier to implement since all locks are held till commit.
Deadlock
Deadlock occurs when each transaction T in a set of two or more transactions is
waiting for some item X, but X is locked by another transaction T ’ in the set. Hence,
each transaction in the set is on a waiting queue, waiting for one of the other transactions
in the set to release the lock on an item.
Deadlock Prevention
1. Use Conservative Locking: every transaction lock all the items it needs in
advance (generally not a practical assumption) —if any of the items cannot be
obtained, none of the items are locked. Rather, the transaction waits and then tries
again to lock all the items it needs.
2. Ordering all the items in the database and making sure that a transaction that
needs several items will lock them according to that order.
3. Use of transaction timestamp TS(T), which is a unique identifier assigned to
each transaction. The timestamps are typically ordered based on the order in
which transactions are started; hence, if transaction T1 starts before transaction
T2, then TS(T1) < TS(T2).
Notice that the older transaction T1 has the smaller timestamp value.
Two schemes that prevent deadlock based on time stamps are wait-die and
wound-wait. Suppose that transaction Ti tries to lock an item X, but is not able to
because X is locked by some other transaction Tj with a conflicting lock. The
rules followed by these schemes are as follows:
• wait-die: if TS(Ti) < TS (Tj) then (Ti older than Tj) Ti is allowed to wait
otherwise (Ti younger than Tj) abort Ti (Ti dies) and restart it later with
the same timestamp.
• wound-wait: if TS(Ti) < TS(Tj) then (Ti older than Tj) abort Tj (Ti
wounds Tj) and restart it later with the same timestamp. otherwise (Ti
younger than Tj) Ti is allowed to wait
4. No waiting: In case of inability to obtain a lock, a transaction aborts and is
resubmitted with a fixed delay. (Causes too many needless aborts).
5. Cautious Waiting: Suppose that transaction Ti tries to lock an item X but is not
able to do so because X is locked by some other transaction Tj with a conflicting
lock.if Tj is not blocked (not waiting for some other locked item) then Ti is
blocked and allowed to wait otherwise abort Ti i.e., if X is waiting for Y, let it
wait unless Y is also waitiing for Z to release some other item.
Basic TO Algorithm
• Whenever some transaction T tries to issue a read_item(X) or a
write_item(X) operation, The basic TO algorithm compares the
timestamp of T with the read timestamp: read_TS(X) and the write
timestamp: write_TS(X) to ensure that the timestamp order of transaction
execution is not violated.
• Thomas’s Write Rule: Thomas’ write rule, does not enforce conflict
serializability; but it rejects fewer write operations, by modifying the checks for
the write_item(X) operation as follows:
1. If read_TS(X) > TS(T), then abort and roll back T and reject the operation.
2. If write_TS(X) > TS(T), then do not execute the write operation but
continue processing. [THIS IS A REJECTED WRITE. This is because
some transaction with timestamp greater than TS(T) and hence after T in
the timestamp ordering has already written the value of X. Hence, we must
ignore the write_item(X) operation of T because it is already outdated and
obsolete. Notice that any conflict arising from this situation would be
detected by case (a).]
3. If neither the condition in part (a) nor the condition in part (b) occurs, then
execute the write_item(X) operation of T and set write_TS(X) to TS(T).
• This approach maintains a number of versions of a data item and allocates the
right version to a read operation of a transaction. Thus unlike other mechanisms a
read operation in this mechanism is never rejected.
• Side effect: Significantly more storage (RAM and disk) is required to maintain
multiple versions.
Multiversion technique based on timestamp ordering
Assume X1, X2, …, Xn are the version of a data item X created by a write
operation of transactions. With each Xi a read_TS (read timestamp) and a
write_TS (write timestamp) are associated.
• read_TS(Xi): The read timestamp of Xi is the largest of all the timestamps of
transactions that have successfully read version Xi.
• write_TS(Xi): The write timestamp of Xi is the timestamp of transaction that
wrote the value of version Xi.
• A new version of Xi is created only by a write operation.
• To ensure serializability, the following two rules are used.
o If transaction T issues write_item (X) and version i of X has the highest
write_TS(Xi) of all versions of X that is also less than or equal to TS(T),
and read _TS(Xi) > TS(T), then abort and roll-back T; otherwise create a
new version Xi and set read_TS(X) = write_TS(Xj) = TS(T).
o If transaction T issues read_item (X), find the version i of X that has the
highest write_TS(Xi) of all versions of X that is also less than or equal to
TS(T), then return the value of Xi to T, and set the value of read _TS(Xi)
to the largest of TS(T) and the current read_TS(Xi).
• Rule 2 guarantees that a read will never be rejected.
The following diagram illustrates a hierarchy of granularity from coarse (database) to fine
(record).
DB
f1 f2
IS IX S SIX X
IS yes yes yes yes no
IX yes yes no no no
S yes no yes no no
SIX yes no no no no
X no no no no no