Con Currency Control

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
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.
s-lock x-lock
s-lock
x-lock

The Basic Locking Protocol
T1 T2
• The basic locking protocol
x-lock(A)
guarantees that
read(A)
– no transaction modifies the same
write(A)
data item at the same time.
unlock(A)
– No transaction modifies the data
s-lock(A) item that is being read.
s-lock(B) – No transaction reads the data
read(A) item that is being modified.
read(B) • However, the basic locking
unlock(A) protocol does not guarantee
unlock(B) serializable schedules.
x-lock(B)
read(B)
write(B) T1 T2
unlock(B)

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
T1 T2
x-lock(A)
read(A) • Serializability
lock
write(A) – T1 and T2 both use 2PL.

x-lock(B)
– This schedule is
unlock(A)
equivalent to T1ÆT2.
s-lock(A)
(see the dashed arrow;
unlock
read(A)
connecting lock points)
read(B)
lock
write(B)
unlock(B)
s-lock(B)
unlock(A)
unlock
read(B)
unlock(B)
2PL vs. Recoverability
T1 T2
x-lock(A) • 2-Phase Locking Protocol
read(A) – does not guarantee recoverable
write(A) schedules
x-lock(B) – because transactions (i.e., T1)
unlock(A) may release locks on modified
s-lock(A) data items (i.e., A and B)
before it commits or aborts
read(A)
– which allows other transactions
read(B)
(i.e., T2) to use the unstable values
write(B) (not committed yet) and
unlock(B) commits beforehand.
s-lock(B) – If it (T1) eventually aborts,
unlock(A) transactions (T2) that read its
read(B)
unstable values must abort too
even though it has already
unlock(B)
committed.
commit
abort
Strict 2PL and Rigorous 2PL
Strict 2PL • Strict 2PL Rigorous 2PL
T1 T2 – Same as 2PL but T1 T2
s-lock(A) – Hold all exclusive locks s-lock(A)
read(A) until the transaction has read(A)
already successfully
s-lock(A) committed or aborted. s-lock(A)
x-lock(B) – It guarantees cascadeless x-lock(B)
unlock(A) recoverability. read(A)
read(B) • Rigorous 2PL read(B)
write(B) – Same Strict 2PL but write(B)
– Hold all locks until the
read(A) commit
transaction has already
unlock(A) successfully committed unlock(B)
commit or aborted. s-lock(B)
unlock(B) – It is used in dynamic
read(B)
environments where data
s-lock(B) access patterns are not unlock(A)
read(B) known beforehand. commit
unlock(B) unlock(A)
commit unlock(B)
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
T1 T2 • Suppose: there are 2 transactions:
s-lock(A) – T1 wants to read A and B;
read(A) then wants to write A later.
– T2 wants to read A and B.
s-lock(A)
s-lock(B) – In the beginning, T1 gets an s-lock on A for
read(B) a read operation. Then it needs to write A,
wait for
so it tries to upgrade the s-lock to an x-lock
on A (see the dash-dotted arrow) but it gets
s2x-lock(A) blocked because T2 holds an s-lock on A
read(A) (i.e., a lock conflict; see the dotted arrow).
s-lock(B) After T2 releases the s-lock on A, T1 can
upgrade the s-lock to an x-lock on A
read(B) (see the dashed arrow).
commit
unlock(A) – If T1 gets an x-lock on A at the beginning,
T2 would have never been allowed to get
s2x-lock(A)
an s-lock on A, thus concurrent execution
unlock(B) of T1 and T2 would not happen. So, high
write(A) concurrency will not be achieved.

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 T2 T3 – T1 waits for T2 to release B.
s-lock(A) – T2 waits for T3 to release C.
– T3 waits for T1 to release A.
read(A)
– No one can proceed.
s-lock(B)
• Wait-For Graph
read(B) – A graph that shows the relationships
s-lock(C) among transactions that wait for wait for
one another to release the resources
read(C) they request for.
wait for – An arrowed line points from the waiting
x-lock(B) transaction to the transaction that holds
a lock on the resource in an incompatible
wait for mode.
x-lock(C) – If there is a directed path that forms
a cycle in the graph, a deadlock occurs.
wait for
x-lock(A)
T1 T2
No one can proceed.
T3
Livelock and Prevention
• Livelock
T1 T2 T3 T4 – T2 cannot get an x-lock on A
s-lock(A) because T1 holds an s-lock on A.
wait for – T3 and T4 can get s-locks on A
x-lock(A) because they are compatible with
the s-lock on A that T1 holds.
read(A)
– There is a chance that T2 will
s-lock(A)
never get the x-lock it requests.
unlock(A)
• Prevention
s-lock(A)
– Do not allow any transaction to
x-lock(B) get a lock on the data item it
read(A) requests if that lock request is
unlock(A) incompatible with one of the
read(A) previous lock requests.
read(B) – Implementation: for each data
item, there is a lock queue to
…
guarantee fairness on data
access.
Lock Upgrade and Deadlock
• Deadlock due to
T1 T2 a Lock Upgrade
s-lock(A) – In a situation where two
read(A) transactions share an access
to the same data item through
s-lock(A)
s-locks, if both of them want to
read(A)
upgrade their s-locks to x-locks,
wait for
s2x-lock(A) none of them will be able to
wait for proceed because each transaction
s2x-lock(A) will be blocked by the other
No one can proceed. transaction due to a lock conflict.
T1 T2

Update Lock Mode (U-Lock)
s-lock u-lock x-lock
• To prevent a deadlock
due to a lock upgrade s-lock
– An update lock mode is introduced u-lock
to prevent a deadlock due to multiple
requests on a lock upgrade on the x-lock
same data item.
– Each transaction should inform T1 T2 T3
the DBMSs in advance if it plans to u-lock(A)
upgrade its s-lock to an x-lock later.
– That is, the transaction should request read(A)
an update lock (u-lock) instead of an s-lock(A)
s-lock at the beginning if it plans to
upgrade the lock to an x-lock later. wait for
– A u-lock is compatible with s-locks u-lock(A)
on the same data item but it is read(A)
incompatible with another u-lock
and x-locks on the same data item. unlock(A)
– The u-lock mode u2x-lock(A)
increases concurrency write(A)
and decreases deadlock
but requires extra information. unlock(A)
u-lock(A)
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.
Let T1, T2, and T3 have higher priorities than T2, T3, and T4 respectively.
(a) High-priority transactions wait (b) Low-priority transactions wait

for a lower-priority transaction. for a higher-priority transaction.
T1 a T2 b
T1 T2
a
b
T4 a T3 T4 b T3
(a) and (b) but no directed cycle. (a) and (b) with a directed cycle.
So, no deadlock. So, a deadlock.
T1 a T2 T1 T2
a b
b b
T4 T3 T4 b T3
a
If (a) and (b) do not occur together, no deadlock.

If (a) and (b) occur together, there may be a deadlock or no deadlock.
• 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
T1 T2 T3 • Wait-Die Approach
– If the aborted (low priority)
In this situation, the wait-die transactions restart (as a new
approach will rollback T3 because transaction with an even lower
T3 gets blocked by a higher priority), there is a chance that
priority transaction (T2) while the they will get blocked by the same
high priority transactions. So, they
wound-wait approach will rollback will have to rollback again.
T2 because T2 blocks a higher
• Wound-Wait Approach
priority transaction (T1). No
– If the aborted (low priority)
deadlock can occur in either transactions restart (as a new
case. transaction with an even lower
priority), there is a chance that
A real deadlock might not occur they will get blocked by the high
priority transactions that hurt them.
at all even though no transaction However, this time, they can wait
got aborted. Both approaches because they are the low priority
may abort transactions transactions that get blocked. No
unnecessary. rollback is necessary.
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 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.

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

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
IS S IX SIX X
IS
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.

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 Answers


Con Currency Control

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Con Currency Control

Încărcat de

Drepturi de autor:

Formate disponibile

Database Management Systems

DBMS: Concurrency Control 1 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 3 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 4 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 5 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 6 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 7 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 8 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 9 Dr. Kriengkrai Porkaew

write(A) – T1 and T2 both use 2PL.

DBMS: Concurrency Control 14 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 15 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 16 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 19 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 21 Dr. Kriengkrai Porkaew

(a) High-priority transactions wait (b) Low-priority transactions wait

If (a) and (b) do not occur together, no deadlock.

DBMS: Concurrency Control 26 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 27 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 31 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 32 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 33 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 34 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 35 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 37 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 38 Dr. Kriengkrai Porkaew

DBMS: Concurrency Control 39 Dr. Kriengkrai Porkaew

Questions and Answers

S-ar putea să vă placă și