Database Management Systems

Concurrency Control

DBMS: Concurrency Control

1

Dr. Kriengkrai Porkaew

Objectives and Outline
• Objectives and Outline
– To study …
• • • • • • • • • • The concepts of concurrency control Lock-based concurrency control protocols Basic locking protocol 2-Phase Locking Protocol (2PL) Deadlock handling Timestamp Ordering Protocol (TO) Validation-based protocol Multiple Granularity Locking and Intension Locks Phantom Phenomenon SQL and Concurrency Control
2 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control

Concurrency Control
• Concurrency Control Protocols
– Are mechanisms to control concurrency of transactions to ensure isolation of transactions (or serializable schedules)

• Pessimistic Concurrency Control Protocols
– Prevent transactions from perform actions that may lead to violation of isolation – E.g., 2-Phase Locking Protocol, Timestamp Ordering Protocol

• Optimistic Concurrency Control Protocols
– Allow transactions to perform actions freely and abort some transactions if they violate isolation property – E.g., Validation-based Protocol
DBMS: Concurrency Control 3 Dr. Kriengkrai Porkaew

Concurrency Control Protocols
• Pessimistic Concurrency Control Protocols
– Good for update-intensive environment – Inefficient if most transactions are read-only

• Optimistic Concurrency Control Protocols
– Good for read-intensive environment – Too many rollbacks/abort of transactions if most transactions are update transactions

DBMS: Concurrency Control

4

Dr. Kriengkrai Porkaew

Lock-based Protocols
• Lock-based Concurrency Control Protocols
– Each transaction must obtain a lock on the data item that it wants to access before it accesses the data item. – After it does not need to use the data item, it may release the lock on the data item. – After the transaction completes, it must release all locks it holds. – A lock manager decides which transaction gets the lock it requests and which transaction has to wait for the lock.
DBMS: Concurrency Control 5 Dr. Kriengkrai Porkaew

A Basic Locking Protocol
• A Basic Locking Protocol
– There are two lock modes:
• Shared Mode (S-Lock / s)
– Each transaction needs to obtain a shared lock on the data item that it wants to read. – Multiple transactions may hold shared locks on the same data item at the same time.

• Exclusive Mode (X-Lock / x)
– Each transaction needs to obtain an exclusive lock on the data item that it wants to modify. – There is at most one transaction that can hold an exclusive lock on a data item at a time.

• Lock Compatibility
– A shared lock and an exclusive lock cannot be held on the same data item at the same time.

DBMS: Concurrency Control

6

Dr. Kriengkrai Porkaew

Lock Compatibility Matrix
• Lock Compatibility Matrix
– Multiple s-locks on the same data item can be held at the same time by different transactions. – Otherwise, all other locks on the same data item cannot be held at the same time by different transactions.

s-lock s-lock x-lock
DBMS: Concurrency Control 7

x-lock

Dr. Kriengkrai Porkaew

The Basic Locking Protocol
T1 x-lock(A) read(A) write(A) unlock(A) s-lock(A) s-lock(B) read(A) read(B) unlock(A) unlock(B) x-lock(B) read(B) write(B) unlock(B)
DBMS: Concurrency Control 8 Dr. Kriengkrai Porkaew

T2

• The basic locking protocol guarantees that
– no transaction modifies the same data item at the same time. – No transaction modifies the data item that is being read. – No transaction reads the data item that is being modified.

• However, the basic locking protocol does not guarantee serializable schedules.

T1

T2

2-Phase Locking Protocol (2PL)
• 2-Phase Locking Protocol
– Guarantees serializable schedules.

• The protocol
– Each transaction performs the basic locking protocol. – Each transaction must acquire all locks it needs (called “Lock Growing Phase”) before it can release any lock it has acquired (called “Lock Shrinking Phase”).

• Serializability Order
– The chronological order that each transaction acquires its last lock (called “Lock Point”).
DBMS: Concurrency Control

9

Dr. Kriengkrai Porkaew

2PL vs. Serializability
T1 x-lock(A) T2

lock

read(A) write(A) x-lock(B) unlock(A) s-lock(A)

• Serializability
– T1 and T2 both use 2PL. – This schedule is equivalent to T1 T2. (see the dashed arrow; connecting lock points)
lock

unlock

read(A) read(B) write(B) unlock(B) s-lock(B) unlock(A) read(B) unlock(B)

unlock

DBMS: Concurrency Control

10

Dr. Kriengkrai Porkaew

2PL vs. Recoverability
T1 x-lock(A) read(A) write(A) x-lock(B) unlock(A) s-lock(A) read(A) read(B) write(B) unlock(B) s-lock(B) unlock(A) read(B) unlock(B) commit abort
DBMS: Concurrency Control 11 Dr. Kriengkrai Porkaew

T2

• 2-Phase Locking Protocol
– does not guarantee recoverable schedules – because transactions (i.e., T1) may release locks on modified data items (i.e., A and B) before it commits or aborts – which allows other transactions (i.e., T2) to use the unstable values (not committed yet) and commits beforehand. – If it (T1) eventually aborts, transactions (T2) that read its unstable values must abort too even though it has already committed.

Strict 2PL and Rigorous 2PL
Strict 2PL T1 s-lock(A) read(A) s-lock(A) x-lock(B) unlock(A) read(B) write(B) read(A) unlock(A) commit unlock(B) s-lock(B) read(B) unlock(B) commit
DBMS: Concurrency Control 12

• Strict 2PL
– Same as 2PL but – Hold all exclusive locks until the transaction has already successfully committed or aborted. – It guarantees cascadeless recoverability.

Rigorous 2PL T1 s-lock(A) read(A) s-lock(A) x-lock(B) read(A) read(B) write(B) commit unlock(B) s-lock(B) read(B) unlock(A) commit unlock(A) unlock(B)
Dr. Kriengkrai Porkaew

T2

T2

• Rigorous 2PL
– Same Strict 2PL but – Hold all locks until the transaction has already successfully committed or aborted. – It is used in dynamic environments where data access patterns are not known beforehand.

Lock Conversion
• Lock Conversion
– Each transaction only acquires the right lock mode at the right time.
• Transactions acquire an s-lock before a read operation. • Transactions acquire an x-lock before a write operation. • Each transaction acquires an s-lock on the data item that it needs to read. Later on, it can upgrade the s-lock to an x-lock when it needs to update that data item (as long as there is no lock conflict with other transactions).

– Similarly, transactions may downgrade an x-lock to an s-lock. – Lock conversion allows higher concurrency.

• Lock Conversion and Strict/Rigorous 2PL
– Lock upgrade (x2s-lock) is considered as acquiring an x-lock, which is a part of the lock growing phase. – Lock downgrade (s2x-lock) is considered as releasing an x-lock (but still holding an s-lock), which is a part of the lock shrinking phase. – Note: for recoverable schedules, lock downgrade is meaningless because locks can only be downgraded (i.e., releasing an x-lock) after transactions have already committed or aborted; where read/write operations are not allowed.
DBMS: Concurrency Control 13 Dr. Kriengkrai Porkaew

Automatic Lock Acquisition
• Automatic Lock Acquisition
– In many dominate database products, locks are acquired automatically and implicitly to ensure correctness of the databases. – Transactions’ read/write operations are preceded by the right lock acquisition controlled by the DBMSs. – Locks are upgraded as needed. – Locks are released after transactions have already committed or aborted successfully to ensure cascadeless recoverability.
DBMS: Concurrency Control 14 Dr. Kriengkrai Porkaew

Automatic Lock Acquisition and Conversion
T1 s-lock(A) read(A) s-lock(A) s-lock(B) read(B) wait for s2x-lock(A) read(A) s-lock(B) read(B) commit unlock(A) s2x-lock(A) unlock(B) write(A)
DBMS: Concurrency Control

T2

• Suppose: there are 2 transactions:
– T1 wants to read A and B; then wants to write A later. – T2 wants to read A and B. – In the beginning, T1 gets an s-lock on A for a read operation. Then it needs to write A, so it tries to upgrade the s-lock to an x-lock on A (see the dash-dotted arrow) but it gets blocked because T2 holds an s-lock on A (i.e., a lock conflict; see the dotted arrow). After T2 releases the s-lock on A, T1 can upgrade the s-lock to an x-lock on A (see the dashed arrow). – If T1 gets an x-lock on A at the beginning, T2 would have never been allowed to get an s-lock on A, thus concurrent execution of T1 and T2 would not happen. So, high concurrency will not be achieved.
15 Dr. Kriengkrai Porkaew

Problems in Lock-based Protocols
• Deadlock
– A transaction (e.g., T1) may be blocked by another transaction (e.g., T2) because it (T1) tries to get a lock on the data item that the second transaction (T2) holds a lock on in an incompatible lock mode. – If multiple transactions blocks one another circularly, no transaction can proceed. This situation is called “Deadlock”. – 2PL guarantees serializable schedules but it may cause a deadlock.

Livelock (Starvation)
– In case that many transactions want to read the same data item, they can share the data item by acquiring s-locks on that data item. – If another transaction (Tx) wants to modify that data item, it needs to request an x-lock on that data item. – In such a situation, it (Tx) has to wait until no other transaction holds a lock on that data item in an incompatible mode. – If there are so many transactions keeping requesting for an s-lock on that data item and keep getting the s-locks they request, the transaction (Tx) that waits for an x-lock on that data item will probably never get the x-lock it requests and waits for. – This situation is called “Livelock” or “Starvation”.

DBMS: Concurrency Control

16

Dr. Kriengkrai Porkaew

Deadlock and Wait-For Graph
• Deadlock
T1 s-lock(A) read(A) s-lock(B) read(B) s-lock(C) read(C) wait for x-lock(B) wait for x-lock(C) wait for x-lock(A) No one can proceed. T2 T3

– – – –

T1 waits for T2 to release B. T2 waits for T3 to release C. T3 waits for T1 to release A. No one can proceed.

• Wait-For Graph
– A graph that shows the relationships among transactions that wait for wait for one another to release the resources they request for. – An arrowed line points from the waiting transaction to the transaction that holds a lock on the resource in an incompatible mode. – If there is a directed path that forms a cycle in the graph, a deadlock occurs.

T1 T3

T2

DBMS: Concurrency Control

17

Dr. Kriengkrai Porkaew

Livelock and Prevention
• Livelock
T1 s-lock(A) wait for x-lock(A) read(A) s-lock(A) unlock(A) s-lock(A) x-lock(B) read(A) unlock(A) read(A) read(B) … T2 T3 T4

– T2 cannot get an x-lock on A because T1 holds an s-lock on A. – T3 and T4 can get s-locks on A because they are compatible with the s-lock on A that T1 holds. – There is a chance that T2 will never get the x-lock it requests.

• Prevention
– Do not allow any transaction to get a lock on the data item it requests if that lock request is incompatible with one of the previous lock requests. – Implementation: for each data item, there is a lock queue to guarantee fairness on data access.
Dr. Kriengkrai Porkaew

DBMS: Concurrency Control

18

Lock Upgrade and Deadlock
T1 s-lock(A) read(A) s-lock(A) read(A) wait for s2x-lock(A) wait for s2x-lock(A) No one can proceed. T2

• Deadlock due to a Lock Upgrade
– In a situation where two transactions share an access to the same data item through s-locks, if both of them want to upgrade their s-locks to x-locks, none of them will be able to proceed because each transaction will be blocked by the other transaction due to a lock conflict. T1 T2
Dr. Kriengkrai Porkaew

DBMS: Concurrency Control

19

Update Lock Mode (U-Lock)
• To prevent a deadlock due to a lock upgrade
– An update lock mode is introduced to prevent a deadlock due to multiple requests on a lock upgrade on the same data item. – Each transaction should inform the DBMSs in advance if it plans to upgrade its s-lock to an x-lock later. – That is, the transaction should request an update lock (u-lock) instead of an s-lock at the beginning if it plans to upgrade the lock to an x-lock later. – A u-lock is compatible with s-locks on the same data item but it is incompatible with another u-lock and x-locks on the same data item. – The u-lock mode increases concurrency and decreases deadlock but requires extra information.
DBMS: Concurrency Control 20

s-lock u-lock x-lock s-lock u-lock x-lock
T1 u-lock(A) read(A) s-lock(A) wait for u-lock(A) read(A) unlock(A) u2x-lock(A) write(A) unlock(A) u-lock(A)
Dr. Kriengkrai Porkaew

T2

T3

Deadlock Handling
• There are three types of deadlock handling techniques.
– Deadlock Prevention (pessimistic)
• dismiss all possible deadlocks before they occur. • Techniques: priority-based approaches.

– A Timeout-based Approach
• just wait for a certain period of time.

– Deadlock Detection and Recovery (optimistic)
• let deadlocks occur, and recover from them. • Technique: Cycle detection in the wait-for graph.
DBMS: Concurrency Control 21 Dr. Kriengkrai Porkaew

Priority-based Deadlock Prevention
• Concepts in Priority-based Approaches
– Assign different priorities to different transactions. – The priority of a transaction may be the timestamp of the transaction when it starts. That is, the oldest transaction (T1) has the highest priority (1). – If there is a possibility of a deadlock, higher-priority transactions will proceed while lower-priority transactions may need to rollback. – A deadlock cannot occur if there is, at most, only one (but not both) of the following situations:
• (a) high-priority transactions wait for a lower-priority transaction • (b) low-priority transactions wait for a higher-priority transaction

– To prevent a deadlock, only allow either one of these situations to occur but do not allow both situations to occur together.
DBMS: Concurrency Control 22 Dr. Kriengkrai Porkaew

Priority-based Deadlock Prevention
Let T1, T2, and T3 have higher priorities than T2, T3, and T4 respectively. (a) High-priority transactions wait for a lower-priority transaction. a T2 T1 a T4 T3 a (a) and (b) but no directed cycle. So, no deadlock. a T2 T1 b b T4 T3 a (b) Low-priority transactions wait for a higher-priority transaction. b T2 T1 b T4 T3 b (a) and (b) with a directed cycle. So, a deadlock. T2 T1 a b T4 T3 b

If (a) and (b) do not occur together, no deadlock. If (a) and (b) occur together, there may be a deadlock or no deadlock.
DBMS: Concurrency Control 23 Dr. Kriengkrai Porkaew

Priority-based Deadlock Prevention
• Wait-Die Approach (non-preemptive)
– Wait: high-priority wait
• If a high priority transaction get blocked by a lower priority transaction, let the high priority transaction wait for the lower priority transaction to finish.

– Die: low-priority

die

• If a low priority transaction get blocked by a higher priority transaction, rollback the low priority transaction (to avoid a possible deadlock).

• Wound-Wait Approach (preemptive)
– Wound: high-priority take over (preemptive)
• If a high priority transaction get blocked by a lower priority transaction, rollback the lower priority transaction (to avoid a possible deadlock).

– Wait: low-priority

wait

• If a low priority transaction get blocked by a higher priority transaction, let the low priority transaction wait for the higher priority transaction to finish.
DBMS: Concurrency Control 24 Dr. Kriengkrai Porkaew

Wait-Die vs. Wound-Wait
T1 T2 T3

• Wait-Die Approach
– If the aborted (low priority) transactions restart (as a new transaction with an even lower priority), there is a chance that they will get blocked by the same high priority transactions. So, they will have to rollback again.

In this situation, the wait-die approach will rollback T3 because T3 gets blocked by a higher priority transaction (T2) while the wound-wait approach will rollback T2 because T2 blocks a higher priority transaction (T1). No deadlock can occur in either case. A real deadlock might not occur at all even though no transaction got aborted. Both approaches may abort transactions unnecessary.
DBMS: Concurrency Control

• Wound-Wait Approach
– If the aborted (low priority) transactions restart (as a new transaction with an even lower priority), there is a chance that they will get blocked by the high priority transactions that hurt them. However, this time, they can wait because they are the low priority transactions that get blocked. No rollback is necessary.
25 Dr. Kriengkrai Porkaew

Timeout-based Deadlock Handling
• Timeout-based Deadlock Handling
– If a transaction get blocked by another transaction, it will wait for a while (a pre-defined period of time: called a timeout period). – If the blocking does not get clear within the timeout period, the transaction will be aborted.

• Is there a deadlock?
– If there is a deadlock, at least one transaction that involves in the deadlock will get blocked until its timeout expires and be aborted. So, other transactions that involve in the deadlock can proceed. – If there is no deadlock (i.e., it is only a simple longduration blocking of transactions), some transactions may still get blocked until their timeout periods expire. So, they will get aborted wastefully.
DBMS: Concurrency Control 26 Dr. Kriengkrai Porkaew

Deadlock Detection and Recovery
• Deadlock Detection
– Use a wait-for graph to keep track of transactions blocking one another. – If there is a directed cycle in the graph, there must be a deadlock. – If no directed cycle in the graph, no deadlock.

• Deadlock Recovery
– If a deadlock is detected, abort one of the transaction in the cycle to break the cycle.
DBMS: Concurrency Control 27 Dr. Kriengkrai Porkaew

Timestamp Ordering Protocol (TO)
• Each transaction gets a unique timestamp when it enters the system.
– a logical timestamp (time) can be used to simulate a realworld clock. – if Ta enters the system before Tb, Ta.time < Tb.time – These timestamps determine the serializability order of the transactions. – no transactions shares the same timestamp.

• Each data item records the two largest timestamps (i.e., a read timestamp and a write timestamp) of the transactions that access it:
– P.write: the largest timestamp of transactions that write P. – P.read: the largest timestamp of transactions that read P. – These timestamps are used to ensure conflict serializability of schedules.
DBMS: Concurrency Control 28 Dr. Kriengkrai Porkaew

TO Protocol
• When Ta requests a read on data item P
– if Ta.time < P.write
• Ta must abort because a newer transaction has overwritten the old value of P with a new value,

– else
• A read request on P is granted to Ta • if P.read < Ta.time, P.read is updated to Ta.time

• When Ta requests a write on data item P
– if Ta.time < P.read
• Ta must abort since a newer transaction has read the old value of P,

– else if Ta.time < P.write
• Ta must abort because a newer transaction has written a new value of P

– else
• A write request on P is granted to Ta • P.write is updated to Ta.time

• This protocol guarantees the isolation property of the transactions.
– the serializability order of the transactions is the order of timestamp of the transactions.
DBMS: Concurrency Control 29 Dr. Kriengkrai Porkaew

Problems in TO Protocol
• What if a transaction abort on its own?
– P.read and P.write maybe needs to rollback.

• It guarantees
– conflict-serializability through transaction’s timestamp; – no deadlock since there is no lock request.

• it does not guarantee
– recoverability
• A transaction may commit before the transaction that it read a modified data item from, so that it is not recoverable. • This can be solved by locking modified data items until the transactions that modify them have committed and not allowing transactions to read data items that are locked. no deadlock can occur since there is no lock conflict and the serializability order is determined by the timestamp.

– starvation free
• some transactions (especially the long one) may abort again and again since it was passed by newer transactions on read and write requests.
DBMS: Concurrency Control 30 Dr. Kriengkrai Porkaew

Thomas’ Write Rule
• Thomas’ Write Rule
– Enhance TO by allowing view serializable schedules to occur. – Allow a write by an old transaction to be ignored without aborting the transaction if a newer transaction has already written another value before it does.

• Same as TO but when Ta requests a write on data item P
– if Ta.time < P.read
• Ta must abort since a newer transaction has read the old value of P,

– else if Ta.time < P.write
• The write request by Ta on P is just ignored without aborting Ta

– else
• A write request on P is granted to Ta • P.write is updated to Ta.time

• Problem
– There is still a large number of transactions that need to rollback. – Multi-version TO Protocol alternatively remedies this problem by holding multiple versions of each data item and allowing transactions to read old versions of data items as long as serializability property is preserved.
DBMS: Concurrency Control 31 Dr. Kriengkrai Porkaew

Validation-based Protocol
• Each transaction has three phases (with a logical timestamp associated with each phase)
– read phase:
• a transaction can read data item. • T.start is the timestamp when T enters its read phase.

– validation phase:
• a transaction is checked whether it is safe to write and commit. • T.validate is the timestamp when T enters its validation phase.

– write phase:
• a safe transaction can commit while unsafe one aborts. • T.finish: is the timestamp when T finishes its write phase.

• Good and Bad
– guarantee recoverability and prevent cascading abort. – do not prevent starvation. – Optimistic: good for read-only dominant systems.
DBMS: Concurrency Control 32 Dr. Kriengkrai Porkaew

How to Validate a Transaction?
• To validate a transaction Tb,
– for all transaction Ta before Tb (i.e., Ta.validate < Tb.validate), Tb is validated if one of the following condition holds
• Ta.finish < Tb.start – meaning: Ta has committed/aborted before Tb starts. • Tb.start < Ta.finish < Tb.validate and not exist { x | Tb.read(x) and Ta.write(x) } – Meaning: Tb does not write anything that Ta reads (since Ta.finish < Tb.validate) and vice versa (since the “not exist” condition in { … }).

– otherwise
• Tb does not pass the validation process and it must be aborted.

DBMS: Concurrency Control

33

Dr. Kriengkrai Porkaew

Multiple Granularity
• There are multiple levels of data items
– The whole database, a group of relations, a relation, a data page which contains a set of tuples in the same relation, and a tuple. – The hierarchy of data items can be represented as a tree.

• Multi-granularity Locking
– allow to lock data items at different granules to reduce locking overhead and to ensure a high level of serializability. – fine granules:
• Allow high concurrency; but result in a high number of granules and so there is a high lock overhead.

– coarse granules:
• Result in low concurrency; but there is a less number of granules and so there is a low lock overhead.

– Multiple granule size:
• Combine their benefits.
DBMS: Concurrency Control 34 Dr. Kriengkrai Porkaew

Intention Lock Modes
• Intention Lock Modes
– an implementation of multi-granularity locking – allow lock conflict to be checked faster

• There are three additional lock modes
– intention-shared (IS):
• s-lock on a finer granule. • conflict with X-lock.

– intention-exclusive (IX)
• x-lock on a finer granule. • conflict with S, SIX, and X-lock.

– shared and intention-exclusive (SIX)
• s-lock on the granule and x-lock on a finer granule. • conflict with SIX-lock.
DBMS: Concurrency Control 35 Dr. Kriengkrai Porkaew

Lock Compatibility Matrix
IS IS S IX SIX X
DBMS: Concurrency Control 36 Dr. Kriengkrai Porkaew

S

IX

SIX

X

Intention Locks for Multiple Granules
• Locking Order
– Locks are acquired from coarse granules to fine granules. – Locks are released from fine granules to coarse granules.

• Locking
– to lock a granule in an s-lock mode:
• do an is-lock on each of the granule until the desired granule is reached. • Lock the desired granule in the s-lock mode. • E.g., to read a row, acquire an is-lock on the table and the page containing the row, and acquire an s-lock on the row.

– to lock a granule in an x-lock mode:
• do an ix-lock on each of the granule until the desired granule is reached. • Lock the desired granule in the x-lock mode. • E.g., to write a row, acquire an x-lock on the table and the page containing the row, and acquire an x-lock on the row. • E.g., in case that the table must be read to compute something before updating a row in the table, so do an six-lock on the table (to read the table and to modify a part of the table), then an ix-lock on the page, and then an x-lock on the row.
DBMS: Concurrency Control 37 Dr. Kriengkrai Porkaew

Phantom Phenomenon
• Insertion and Deletion operations in a transaction
– similar to write operations – in locking protocols: request an x-lock on the data item – phantom problem:
• the insertion/deletion operations may be transparent to some transactions and not the others • this transparency may cause a schedule to be non-serializable

– phantom protection:
• index locking protocol: – predicate locking, key-range locking

DBMS: Concurrency Control

38

Dr. Kriengkrai Porkaew

SQL and Concurrency Control
• Level of Isolation in SQL
– read uncommitted:
• allows dirty read

– read committed:
• not allow dirty read but repeated reads may get different results

– repeatable read:
• repeated reads get the same result but do not prevent phantom problem

– serializable:
• no phantom problem

• Access Modes
– read-only:
• transactions that only reads data items; allow higher concurrency

– read-write
• transactions may read and write data items
DBMS: Concurrency Control 39 Dr. Kriengkrai Porkaew

Conclusion
• • • • • • • • • • • Concurrency Control Concepts Lock-based Concurrency Control Protocols Basic Locking Protocol 2 Phase Locking Protocol (2PL) Deadlock Handling Timestamp Ordering Protocol (TO) Validation-based Protocol Multiple Granularity Locking Intension Locks Phantom Phenomenon SQL and Concurrency Control

Questions and Answers
DBMS: Concurrency Control 40 Dr. Kriengkrai Porkaew

Sign up to vote on this title
UsefulNot useful