Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe


CHAPTER 21

Concurrency Control Techniques


Introduction

Concurrency control protocols

Set of rules to guarantee serializability

Two-phase locking protocols

Lock data items to prevent concurrent access

Timestamp

Unique identifier for each transaction

Multiversion currency control protocols

Use multiple versions of a data item

Validation or certification of a transaction

Slide 21- 3


21.1 Two-Phase Locking Techniques

for Concurrency Control

Lock

Variable associated with a data item describing

status for operations that can be applied

One lock for each item in the database

Binary locks

Two states (values)

Locked (1)

Item cannot be accessed

Unlocked (0)

Item can be accessed when requested

Slide 21- 4


Two-Phase Locking Techniques

for Concurrency Control (cont’d.)

Transaction requests access by issuing a

lock_item(X) operation

Slide 21- 5

Figure 21.1 Lock and unlock operations for binary locks




Lock table specifies items that have locks

Lock manager subsystem

Keeps track of and controls access to locks

Rules enforced by lock manager module

At most one transaction can hold the lock on an

item at a given time

Binary locking too restrictive for database items

Slide 21- 6




Shared/exclusive or read/write locks

Read operations on the same item are not

conflicting

Must have exclusive lock to write

Three locking operations

read_lock(X)

write_lock(X)

unlock(X)

Slide 21- 7

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21-8

Figure 21.2 Locking and

unlocking operations for

two-mode (read/write, or

shared/exclusive) locks




Lock conversion

Transaction that already holds a lock allowed to

convert the lock from one state to another

Upgrading

Issue a read_lock operation then a write_lock

operation

Downgrading

Issue a read_lock operation after a write_lock

operation

Slide 21- 9


Guaranteeing Serializability by Two-

Phase Locking

Two-phase locking protocol

All locking operations precede the first unlock

operation in the transaction

Phases

Expanding (growing) phase

New locks can be acquired but none can be released

Lock conversion upgrades must be done during this phase

Shrinking phase

Existing locks can be released but none can be acquired

Downgrades must be done during this phase

Slide 21- 10

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 21- 11

Figure 21.3 Transactions that

do not obey two-phase

locking (a) Two transactions

T1 and T2 (b) Results of

possible serial schedules of

T1 and T2 (c) A

nonserializable schedule S

that uses locks


Guaranteeing Serializability by Two-

Phase Locking

If every transaction in a schedule follows the two-

phase locking protocol, schedule guaranteed to

be serializable

Two-phase locking may limit the amount of

concurrency that can occur in a schedule

Some serializable schedules will be prohibited by

two-phase locking protocol

Slide 21- 12


Variations of Two-Phase Locking

Basic 2PL

Technique described on previous slides

Conservative (static) 2PL

Requires a transaction to lock all the items it

accesses before the transaction begins

Predeclare read-set and write-set

Deadlock-free protocol

Strict 2PL

Transaction does not release exclusive locks until

after it commits or aborts

Slide 21- 13


Variations of Two-Phase Locking

(cont’d.)

Rigorous 2PL

Transaction does not release any locks until after it

commits or aborts

Concurrency control subsystem responsible for

generating read_lock and write_lock requests

Locking generally considered to have high

overhead

Slide 21- 14


Dealing with Deadlock and Starvation

Deadlock

Occurs when each transaction T in a set is waiting

for some item locked by some other transaction T’

Both transactions stuck in a waiting queue

Slide 21- 15

Figure 21.5 Illustrating the deadlock problem (a) A partial schedule of T1′ and T2′ that is

in a state of deadlock (b) A wait-for graph for the partial schedule in (a)



(cont’d.)

Deadlock prevention protocols

Every transaction locks all items it needs in

advance

Ordering all items in the database

Transaction that needs several items will lock them

in that order

Both approaches impractical

Protocols based on a timestamp

Wait-die

Wound-wait

Slide 21- 16



(cont’d.)

No waiting algorithm

If transaction unable to obtain a lock, immediately

aborted and restarted later

Cautious waiting algorithm

Deadlock-free

Deadlock detection

System checks to see if a state of deadlock exists

Wait-for graph

Slide 21- 17



(cont’d.)

Victim selection

Deciding which transaction to abort in case of

deadlock

Timeouts

If system waits longer than a predefined time, it

aborts the transaction

Starvation

Occurs if a transaction cannot proceed for an

indefinite period of time while other transactions

continue normally

Solution: first-come-first-served queue Slide 21- 18


21.2 Concurrency Control Based

on Timestamp Ordering

Timestamp

Unique identifier assigned by the DBMS to identify

a transaction

Assigned in the order submitted

Transaction start time

Concurrency control techniques based on

timestamps do not use locks

Deadlocks cannot occur

Slide 21- 19


Concurrency Control Based

on Timestamp Ordering (cont’d.)

Generating timestamps

Counter incremented each time its value is

assigned to a transaction

Current date/time value of the system clock

Ensure no two timestamps are generated during the

same tick of the clock

General approach

Enforce equivalent serial order on the transactions

based on their timestamps

Slide 21- 20




Timestamp ordering (TO)

Allows interleaving of transaction operations

Must ensure timestamp order is followed for each

pair of conflicting operations

Each database item assigned two timestamp

values

read_TS(X)

write_TS(X)

Slide 21- 21




Basic TO algorithm

If conflicting operations detected, later operation

rejected by aborting transaction that issued it

Schedules produced guaranteed to be conflict

serializable

Starvation may occur

Strict TO algorithm

Ensures schedules are both strict and conflict

serializable

Slide 21- 22




Thomas’s write rule

Modification of basic TO algorithm

Does not enforce conflict serializability

Rejects fewer write operations by modifying

checks for write_item(X) operation

Slide 21- 23


21.3 Multiversion Concurrency

Control Techniques

Several versions of an item are kept by a system

Some read operations that would be rejected in

other techniques can be accepted by reading an

older version of the item

Maintains serializability

More storage is needed

Multiversion currency control scheme types

Based on timestamp ordering

Based on two-phase locking

Validation and snapshot isolation techniques

Slide 21- 24


Multiversion Concurrency

Control Techniques (cont’d.)

Multiversion technique based on timestamp

ordering

Two timestamps associated with each version are

kept

read_TS(Xi)

write_TS(Xi)

Slide 21- 25


Multiversion Concurrency

Control Techniques (cont’d.)

Multiversion two-phase locking using certify locks

Three locking modes: read, write, and certify

Slide 21- 26

Figure 21.6 Lock compatibility tables (a) Lock compatibility table for read/write

locking scheme (b) Lock compatibility table for read/write/certify locking scheme


21.4 Validation (Optimistic) Techniques and

Snapshot Isolation Concurrency Control

Optimistic techniques

Also called validation or certification techniques

No checking is done while the transaction is

executing

Updates not applied directly to the database until

finished transaction is validated

All updates applied to local copies of data items

Validation phase checks whether any of

transaction’s updates violate serializability

Transaction committed or aborted based on result

Slide 20- 27


Concurrency Control Based on

Snapshot Isolation

Transaction sees data items based on committed

values of the items in the database snapshot

Does not see updates that occur after transaction

starts

Read operations do not require read locks

Write operations require write locks

Temporary version store keeps track of older

versions of updated items

Variation: serializable snapshot isolation (SSI)

Slide 20- 28


21.5 Granularity of Data Items and

Multiple Granularity Locking

Size of data items known as granularity

Fine (small)

Coarse (large)

Larger the data item size, lower the degree of

concurrency permitted

Example: entire disk block locked

Smaller the data item size, more locks required

Higher overhead

Best item size depends on transaction type

Slide 20- 29


Multiple Granularity Level Locking

Lock can be requested at any level

Slide 21- 30

Figure 21.7 A granularity hierarchy for illustrating multiple granularity level locking



(cont’d.)

Intention locks are needed

Transaction indicates along the path from the root

to the desired node, what type of lock (shared or

exclusive) it will require from one of the node’s

descendants

Intention lock types

Intention-shared (IS)

Shared locks will be requested on a descendant

node

Intention-exclusive (IX)

Exclusive locks will be requested

Slide 21- 31



(cont’d.)

Intention lock types (cont’d.)

Shared-intension-exclusive (SIX)

Current node is locked in shared mode but one or

more exclusive locks will be requested on a

descendant node

Slide 21- 32

Figure 21.8 Lock compatibility matrix for multiple granularity locking



(cont’d.)

Multiple granularity locking (MGL) protocol rules

Slide 21- 33


21.6 Using Locks for Concurrency

Control in Indexes

Two-phase locking can be applied to B-tree and

B+ -tree indexes

Nodes of an index correspond to disk pages

Holding locks on index pages could cause

transaction blocking

Other approaches must be used

Conservative approach

Lock the root node in exclusive mode and then

access the appropriate child node of the root

Slide 21- 34


Using Locks for Concurrency

Control in Indexes (cont’d.)

Optimistic approach

Request and hold shared locks on nodes leading

to the leaf node, with exclusive lock on the leaf

B-link tree approach

Sibling nodes on the same level are linked at

every level

Allows shared locks when requesting a page

Requires lock be released before accessing the

child node

Slide 21- 35


21.7 Other Concurrency Control

Issues

Insertion

When new data item is inserted, it cannot be

accessed until after operation is completed

Deletion operation on the existing data item

Write lock must be obtained before deletion

Phantom problem

Can occur when a new record being inserted

satisfies a condition that a set of records accessed

by another transaction must satisfy

Record causing conflict not recognized by

concurrency control protocol Slide 21- 36


Other Concurrency Control Issues

(cont’d.)

Interactive transactions

User can input a value of a data item to a

transaction T based on some value written to the

screen by transaction T′, which may not have

committed

Solution approach: postpone output of

transactions to the screen until committed

Latches

Locks held for a short duration

Do not follow usual concurrency control protocol

Slide 21- 37


21.8 Summary

Concurrency control techniques

Two-phase locking

Timestamp-based ordering

Multiversion protocols

Snapshot isolation

Data item granularity

Locking protocols for indexes

Phantom problem and interactive transaction

issues

Slide 21- 38

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe · 2017. 9. 24. · Copyright © 2016 Ramez...

Documents

Transcript of Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe · 2017. 9. 24. · Copyright © 2016 Ramez...