Upload
abdullah-salem
View
225
Download
0
Embed Size (px)
Citation preview
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 1/35
Lecture 10: Concurrency Control
• Motivating Questions
– How does Concurrency control work ?
– Why is it important for DBMS ?
– What is 2PL?
Connelly & Begg Ch 20
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 2/35
Database Architecture• DBMS transaction subsystem – 4 high level
database modules that handle transactions,
concurrency control and recovery.
• Transaction Manager (TM) – coordinates
transactions on behalf of application
programs• TM communicates with Scheduler/lock
manager – implement strategy to maximize
concurrency control. If failure occurs during
transaction, then database is in inconsistent
state.• Recovery manager ensure database is
restored or consistent state.
• Buffer Manager – responsible for the
efficient transfer of data between disk
storage and main memory.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 3/35
Concurrency Control
• Concurrency control - the process of managing
simultaneous operations on the database without having
them interfere with one another
• Concurrency control is needed to prevent concurrent
transactions from interfering with each other.
• Consider the scenario:
“two or more users accessing database simultaneously
and at least one is updating data, there may be
interference that can result in inconsistencies”
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 4/35
Concurrency Control
• Interleaved transaction - allows multiple users of the
database to access it at the same time.
• While one transaction is performing an I/O task, another
one can perform a CPU-intensive task thus maximising the
throughput of the system.
• Throughput – the amount of work that is accomplished in
a given time interval
• Interleaving of operations may produce an incorrect
result/problems, thus compromising the integrity and
consistency of the database.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 5/35
Concurrency Control
• Concurrency control is needed to handle problems that can
occur when transactions execute concurrently.
– Lost Update problem: an update to an object by some
transaction is overwritten by another interleaved transaction
without knowledge of the initial update.
– Uncommitted Dependency problem: a transaction reads an
object updated by another transaction that later falls.
– Inconsistent Analysis problem: a transaction calculating anaggregate function uses some but not all updated objects of
another transaction.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 6/35
Lost Update Example
Time T1 T2 balx
t1
t2
t3
t4 t5
t6
begin_transaction
read(balx)
balx = balx - 100write (balx)
commit
begin_transaction
read(balx)
balx = balx + 100
write (balx)commit
100
100
100
20090
90
• T1 and T2 start at nearly the same time, both read the balance as RM100.
• T2
increased balx
by RM100 to RM200 and stores the update in the database
• Meanwhile T1 decrements its copy of balx, by RM10 to RM90 and stores in
database, overwriting the previous update, and loosing the RM100 previously
added to the balance.
• The loss of T 2’s update is avoided by preventing T 1 from sending the value of
bal x until after T 2’s update has been completed
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 7/35
Lost Uncommited dependency
(or dirty read)
• T4 updates balx to RM200 but it aborts the transaction so that balx should be restored to its
original value of RM100.
• By this time T3 has read the new value of balx RM200 and is using this value as the basis of
the RM10 reduction, giving a new incorrect balance of RM190, instead of RM90.
• The value of balx read by T3 is called dirty data, giving rise to the alternative name, the
dirty read problem
• The problem is avoided by preventing T 3 from reading bal x until after the decision has been
made to either commit or abort T 4 ‘s effect
Time T3 T4 balx
t1 t2
t3
t4
t5
t6
t7
t8
begin_transaction
read(balx)
balx = balx + 10
write (balx)
commit
begin_transactionread(balx)
balx = balx + 100
write (balx)
:
rollback
100100
100
200
200
100
190
190
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 8/35
Lost Update Example
read (R)
Add 50 to R
read (R)
Add 100 to R
write (R)
write (R)
TA TB
Transaction A‟s update is lost
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 9/35
Locks
• In order to execute transactions in an interleavedmanner it is necessary to have some form ofconcurrency control.
• This enables a more efficient use of computerresources.
• One method of avoiding problems is with the use
of locks.• When a transaction requires a database object it
must obtain a lock.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 10/35
Lock Manager
• A lock is obtained from a system component called thelock manager.
• There are usually two types of lock an exclusive lock (X)
and a shared lock (S).• The lost update problem can easily be handled by X
locks.
• When a transaction intends to update an object it must
obtain an X lock on it. If one is not available it must wait.• Transaction A can obtain an X lock on R and then
Transaction B will have to wait before it can have an Xlock on R.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 11/35
Lost Update Solution
Begin
x_lock(R)
read (R)Add 50 to R Begin
x_lock(R)
wait
write (R) wait
Commit/unx_lock(R) waitread (R)
Add 100 to R
write (R)
commit/unx_lock(R)
TA TB
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 12/35
Uncommitted Dependency Example
read (R)
Subtract 50 from R
write (R)
read (R)
Add 75 to R
write (R)
ROLLBACK
TA TB
Transaction B reads an uncommitted value for R
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 13/35
Uncommitted Dependency Example
• Problems can still occur if a transaction is ROLLED back.
• The uncommitted dependency problem can be solved by
an extension to the locking protocol.
• Exclusive locks are retained until the end of a transaction.
• Transaction B would not be allowed an X lock on R until
transaction B had completed (either COMMITT or ROLL
BACK).
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 14/35
Uncommitted Dependency Solution #
Begin
x_lock(R)
read (R)Subtract 50 from R Begin
x_lock(R)
wait
write (R) wait
Rollback/unx_lock(R) waitread (R)
Add 75 to R
write (R)
commit/unx_lock(R)
TA TB
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 15/35
Inconsistent Analysis Example
read (ACC1)
SUM = ACC1
read (ACC2)
SUM = SUM + ACC2read (ACC1)
ADD 10 to ACC1
read (ACC3)
SUBTRACT 10 from ACC3
WRITE(ACC3)
COMMIT
read (ACC3)
SUM = SUM + ACC3
TA TB
The value in SUM will be inconsistent.
Required SUM = 120 but is 110.
ACC1 = 30
ACC2 = 40
ACC3 = 50
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 16/35
Inconsistent Analysis Problem
• A transaction may need to keep an object locked
even if it is not updating it.
• In the Inconsistent analysis problem it isnecessary for Transaction A to obtain an S lock on
each account and retain these locks until the
transaction is complete.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 17/35
Inconsistent Analysis Solution #
Begin
s_lock(ACC1), s_lock(ACC2),s_lock(ACC3)
read (ACC1)
SUM = ACC1
read (ACC2)
SUM = SUM + ACC2 Begin
x_lock(ACC1),x_lock(ACC3)
wait
read (ACC3) wait
SUM = SUM + ACC3 wait
uns_lock(ACC1),uns_lock(ACC2),uns_lock(ACC3) wait
read (ACC1)
Add 10 to ACC1
read (ACC3)
subtract 10 from ACC3
write(ACC3)commit/unx_lock(ACC1),unx_lock(ACC3)
TATB
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 18/35
• Locking - a procedure used to control concurrent access todata. When one transaction is accessing the database, a lock maydeny access to other transactions to prevent incorrect results.
• Locking methods widely used approach to ensure serialisabilityof concurrent transactions.
• Transaction will claim shared lock (read) or exclusive lock(write) on a data item before the corresponding database read orwrite operation.
• Shared lock – if a transaction has a shared lock on a data item,it can read the item but not update it
• Exclusive lock – if a transaction has an exclusive lock on a dataitem, it can both read and update the item.
Locking Methods
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 19/35
• Locks can only be acquired according to the compatibilitymatrix.
TA hasS XTB requests S Y N
X N N
• A transaction may set a lock on an item if this lock iscompatible with locks already held on the item by othertransactions
Lock Compatibility Matrix
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 20/35
Locking Rules
• Any number of transactions can hold S-locks on an item
• If any transaction holds an X-lock on an item, no other
transaction may hold any lock on the item
• A transaction holding an X-lock may issue a write or a
read request on the data item
• A transaction holding an S-lock may issue a read request
on the data item
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 21/35
Serialisability
• A given interleaved execution of a set of
transactions is considered correct if it is
serialisable.• A given interleaved execution of a set of
transactions is said to be serialisable if and
only if it produces the same results as someserial execution of the same transactions.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 22/35
Justification of Serialisability
• Individual transactions are assumed to be
correct.
• Running the transactions one at a time inany serial order is therefore also correct.
• An interleaved execution is therefore
correct if it is equivalent to some serialexecution; i.e it is serialisable.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 23/35
Serialisability applied to examples
• In the earlier examples the original interleaved
executions were not equivalent to either running
TA then TB or TB then TA.• The effect of locking was to force serialisability.
• It is possible to guarantee serialisability by using
the ‘two-phase locking’ protocol.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 24/35
Two-Phase Locking Protocol (2PL)
• 2PL – a transaction follows the two-phase locking protocol if all
locking operations precede the first unlock operation in the
transaction
1. Before operating on an object, a transaction must acquire a
lock on that object
2. After releasing a lock, a transaction must never acquire any
new locks.
• The protocol guarantees serialisability
• A transaction obeying this protocol will have two phases a
„growing‟ phase during which locks are obtained and a
„shrinking‟ phase when locks are released.
• The shrinking phase is often compressed into the single
operation COMMIT or ROLLBACK.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 25/35
Incorrect Locking Question #
read (A)Add 10 to Awrite (A)
read (B)
subtract 10 from Bwrite (B)
TA TBread (A)A = A * 1.2write (A)read (B)
B = B * 1.2write(B)
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 26/35
Incorrect Locking Answer #
X_lock (A)read (A)Add 10 to Awrite (A)unX_lock(A)
X_lock (A)read (A)A = A * 1.2write (A)X_lock (B)read (B)B = B * 1.2write(B)unX_lock (A),unX_lock (B)
X_lock (B)
read (B)
subtract 10 from B
write (B)
unX_lock(B)
TA TB
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 27/35
Example of 2PL
S_lock (Y)read (Y)X_lock (X)unlock (Y)
X_lock (Y)read (Y)write (Y)
read (X)
write (X)unlock (X)S_lock (X)read (X)unlock (X)unlock (Y)
TA TB
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 28/35
2PL with Lock Conversion
• Growing Phase
– can acquire an S-lock on item
– can acquire an X-lock on item
– can convert an S-lock to an X-lock
• Shrinking Phase
– can release an S-lock
– can release an X-lock
– can convert an X-lock to an S-lock
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 29/35
Deadlock
X_lock (R)read (R)
X_lock (S)read (S)
request X_lock(S)wait request X_lock(R)wait waitwait wait
TA TB
• Deadlock occurs when two transactions are each waiting
for locks held by the other to be released
• Example
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 30/35
Deadlock Prevention
• If a deadlock occurs then the system needs to detect it.
• Detecting deadlock involves detecting a cycle in the ‘wait-
for graph’ i.e the graph of who is waiting for whom.
• Breaking the deadlock then involves choosing one of the
transactions and rolling it back, thereby releasing its locks
and allowing other transactions to proceed.
• In practise some systems just use a timeout mechanism and
assume deadlock if a transaction has done nothing for a
prescribed period of time.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 31/35
Timestamp Protocol
• Each transaction is issued a unique identifier, the
timestamp when it enters the system. Timestamps may be
drawn from an increasing sequence of integers.
• For any given request, the system compares the timestamp
of the requesting transaction with the timestamp of the
transaction that last retrieved or updated that object.
• Conflicts occur if a transaction asks to see an object last
seen or updated by a younger transaction.
• Conflicts are dealt with by restarting the requesting
transaction and assigning it a new timestamp.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 32/35
Timestamp Example #
TB
TA
write(C)
Request read or write on C
Transaction TA
is older than
transaction TBAND
last write is by TB
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 33/35
Timestamp Example #
TB
TAwrite(C)
Request read or write on C
Transaction TA
is younger than
transaction TBAND
last write is by TB
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 34/35
Recovery and Concurrency Control:
Summary• Concurrency control problems occur when transactions are
not serialisable.
• The most widespread technique for dealing with such
problems is locking.
• A set of transactions obeying the two-phase locking
protocol can be guaranteed serialisable.
8/11/2019 IDBE-lectures-10 - Concurrency Control Updated
http://slidepdf.com/reader/full/idbe-lectures-10-concurrency-control-updated 35/35
What You Should Now Know
• What the Lost Update, UncommittedDependency and Inconsistent Analysis
problems are and how they are resolved bylocks.
• How locks work.
• What serialisability is and how 2PL works.
• What deadlock is and how it is prevented.
• What timestamps are and how they work.