Con Currency Control

DBMS: Concurrency Control Dr. Kriengkrai Porkaew1

Database Management Systems

Concurrency Control


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


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


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


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.


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.


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.

��x-lock��s-lock

x-locks-lock


The Basic Locking Protocol• 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.

write(B)

x-lock(B)unlock(B)unlock(A)

read(B)read(A)

s-lock(B)

unlock(B)

read(B)

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

x-lock(A)T2T1

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”).


2PL vs. Serializability

• Serializability– T1 and T2 both use 2PL.– This schedule is

equivalent to T1 T2. (see the dashed arrow; connecting lock points)

read(B)

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

read(A)s-lock(A)

unlock(B)

unlock(A)

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

x-lock(A)T2T1

lock

unlo

ck

lockunlock


2PL vs. Recoverability• 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 tooeven though it has already committed.unlock(B)

read(B)

commit

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

read(A)s-lock(A)

abort

unlock(A)

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

x-lock(A)T2T1


Strict 2PL and Rigorous 2PL• Strict 2PL

– Same as 2PL but– Hold all exclusive locks

until the transaction has already successfullycommitted or aborted.

– It guarantees cascadeless recoverability.

• 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.

Strict 2PL

read(B)unlock(B)

unlock(B)commit

unlock(A)read(A)

write(B)read(B)

commit

s-lock(B)

unlock(A)x-lock(B)

s-lock(A)read(A)

s-lock(A)T2T1

Rigorous 2PL

commitunlock(A)

read(B)s-lock(B)

unlock(B)commitwrite(B)read(B)

unlock(B)

unlock(A)

read(A)x-lock(B)

s-lock(A)read(A)

s-lock(A)T2T1


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.


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.


Automatic Lock Acquisition and Conversion

• 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.

s2x-lock(A)unlock(A)

unlock(B)

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

wait fors2x-lock(A)

write(A)

commit

read(B)s-lock(B)

s-lock(A)read(A)

s-lock(A)T2T1


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”.


Deadlock and Wait-For Graph• Deadlock

– 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.

wait forx-lock(C)

read(B)s-lock(B)

T2

wait forx-lock(A)

wait for x-lock(B)

read(C)

No one can proceed.

s-lock(C)

read(A)s-lock(A)

T3T1

T1 T2

T3


Livelock and Prevention• Livelock

– 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.

read(B)

read(A)unlock(A)

x-lock(B)

…

read(A)

s-lock(A)

T3

wait forx-lock(A)

T2

s-lock(A)unlock(A)

read(A)

s-lock(A)T4T1


Lock Upgrade and Deadlock• 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.

wait fors2x-lock(A)

No one can proceed.

wait for s2x-lock(A)

read(A)s-lock(A)

read(A)s-lock(A)

T2T1

T1 T2


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.

write(A)u2x-lock(A)

unlock(A)

unlock(A)read(A)

s-lock(A)

T2

u-lock(A)

wait foru-lock(A)

read(A)u-lock(A)

T3T1

��

u-lock

��u-lock��x-lock

��s-lockx-locks-lock


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.


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.


Priority-based Deadlock Prevention

(a) High-priority transactions wait for a lower-priority transaction.

(b) Low-priority transactions wait for a higher-priority transaction.

(a) and (b) but no directed cycle. So, no deadlock.

(a) and (b) with a directed cycle.So, a deadlock.

T4

T1 T2

T3 T4

T1 T2

T3

T4

T1 T2

T3 T4

T1 T2

T3

Let T1, T2, and T3 have higher priorities than T2, T3, and T4 respectively.

a

a

a

a

ab

bb

b

b

bba

If (a) and (b) do not occur together, no deadlock. If (a) and (b) occur together, there may be a deadlock or no deadlock.


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.


Wait-Die vs. Wound-Wait• 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.

• 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.

T1 T2 T3In 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.


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 long-duration blocking of transactions), some transactions may still get blocked until their timeout periods expire. So, they will get aborted wastefully.


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.


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 real-

world 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.


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.


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.


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 TThe write request by Taa on P is just ignored without aborting Ton P is just ignored without aborting Taa– 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.


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.


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.


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 lockingoverhead 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.


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.


Lock Compatibility Matrix

�

�

�

�

�

IX

��IX

��SIX

��X

��S

��IS

XSIXSIS


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.


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


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


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 AnswersQuestions and Answers

Con Currency Control

Documents

Transcript of Con Currency Control