IDBE-lectures-10 - Concurrency Control Updated

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



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.



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”



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.



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.



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



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



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



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.



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.



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



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



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



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



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



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.



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



• 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



• 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



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



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.



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.



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.



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.



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)



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



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



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



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



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.



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.



Timestamp Example #

TB

TA

write(C)

Request read or write on C

Transaction TA

is older than

transaction TBAND

last write is by TB



Timestamp Example #

TB

TAwrite(C)

Request read or write on C

Transaction TA

is younger than

transaction TBAND

last write is by TB



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.



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.

IDBE-lectures-10 - Concurrency Control Updated

Documents

Transcript of IDBE-lectures-10 - Concurrency Control Updated