Professional Documents
Culture Documents
Concurrency Ch18 7th Ed
Concurrency Ch18 7th Ed
Lock-Based Protocols
Timestamp-Based Protocols
Validation-Based Protocols
Multiple Granularity
Multiversion Schemes
Insert and Delete Operations
Concurrency in Index Structures
Database System Concepts - 7th Edition 18.2 ©Silberschatz, Korth and Sudarshan
Lock-Based Protocols
Database System Concepts - 7th Edition 18.3 ©Silberschatz, Korth and Sudarshan
Lock-Based Protocols (Cont.)
Lock-compatibility matrix
Database System Concepts - 7th Edition 18.4 ©Silberschatz, Korth and Sudarshan
Schedule With Lock Grants
Grants omitted in rest of
chapter
• Assume grant
happens just before
the next instruction
following lock
request
This schedule is not
serializable (why?)
A locking protocol is a
set of rules followed by
all transactions while
requesting and releasing
locks.
Locking protocols
enforce serializability by
restricting the set of
possible schedules.
Database System Concepts - 7th Edition 18.5 ©Silberschatz, Korth and Sudarshan
Deadlock
Database System Concepts - 7th Edition 18.6 ©Silberschatz, Korth and Sudarshan
Deadlock (Cont.)
The potential for deadlock exists in most locking protocols. Deadlocks are
a necessary evil.
Starvation is also possible if concurrency control manager is badly
designed. For example:
• A transaction may be waiting for an X-lock on an item, while a
sequence of other transactions request and are granted an S-lock on
the same item.
• The same transaction is repeatedly rolled back due to deadlocks.
Concurrency control manager can be designed to prevent starvation.
Database System Concepts - 7th Edition 18.7 ©Silberschatz, Korth and Sudarshan
The Two-Phase Locking Protocol
Locks
• Transaction may not release locks
Phase 2: Shrinking Phase
• Transaction may release locks
Time
• Transaction may not obtain locks
The protocol assures serializability. It can be
proved that the transactions can be
serialized in the order of their lock points
(i.e., the point where a transaction acquired
its final lock).
Database System Concepts - 7th Edition 18.8 ©Silberschatz, Korth and Sudarshan
The Two-Phase Locking Protocol (Cont.)
Database System Concepts - 7th Edition 18.9 ©Silberschatz, Korth and Sudarshan
The Two-Phase Locking Protocol (Cont.)
Database System Concepts - 7th Edition 18.10 ©Silberschatz, Korth and Sudarshan
Locking Protocols
Database System Concepts - 7th Edition 18.11 ©Silberschatz, Korth and Sudarshan
Lock Conversions
Database System Concepts - 7th Edition 18.12 ©Silberschatz, Korth and Sudarshan
Automatic Acquisition of Locks
Database System Concepts - 7th Edition 18.13 ©Silberschatz, Korth and Sudarshan
Automatic Acquisition of Locks (Cont.)
Database System Concepts - 7th Edition 18.14 ©Silberschatz, Korth and Sudarshan
Implementation of Locking
Database System Concepts - 7th Edition 18.15 ©Silberschatz, Korth and Sudarshan
Lock Table
Dark rectangles indicate granted
locks, light colored ones indicate
waiting requests
Lock table also records the type of
lock granted or requested
New request is added to the end of
the queue of requests for the data
item, and granted if it is compatible
with all earlier locks
Unlock requests result in the request
being deleted, and later requests are
checked to see if they can now be
granted
If transaction aborts, all waiting or
granted requests of the transaction
are deleted
• lock manager may keep a list of
locks held by each transaction, to
implement this efficiently
Database System Concepts - 7th Edition 18.16 ©Silberschatz, Korth and Sudarshan
Graph-Based Protocols
Database System Concepts - 7th Edition 18.17 ©Silberschatz, Korth and Sudarshan
Tree Protocol
Database System Concepts - 7th Edition 18.18 ©Silberschatz, Korth and Sudarshan
Graph-Based Protocols (Cont.)
Database System Concepts - 7th Edition 18.19 ©Silberschatz, Korth and Sudarshan
Deadlock Handling
Database System Concepts - 7th Edition 18.20 ©Silberschatz, Korth and Sudarshan
Deadlock Handling
1. Deadlock prevention
2. Deadlock detection and recovery
Database System Concepts - 7th Edition 18.21 ©Silberschatz, Korth and Sudarshan
Deadlock Handling
Database System Concepts - 7th Edition 18.22 ©Silberschatz, Korth and Sudarshan
Deadlock Handling
First scheme under First approach: It requires that each transaction locks
all its data items before it begins execution. Moreover, either all are locked in
one step or none are locked.
There are two main disadvantages to this protocol:
(1) it is often hard to predict, before the transaction begins, what data items
need to be locked;
(2) data-item utilization may be very low, since many of the data items may
be locked but unused for a long time.
Database System Concepts - 7th Edition 18.23 ©Silberschatz, Korth and Sudarshan
Deadlock Handling
Database System Concepts - 7th Edition 18.24 ©Silberschatz, Korth and Sudarshan
Deadlock Prevention (2nd Approach)
Database System Concepts - 7th Edition 18.25 ©Silberschatz, Korth and Sudarshan
Deadlock Prevention (2nd Approach)
Database System Concepts - 7th Edition 18.26 ©Silberschatz, Korth and Sudarshan
Deadlock Prevention (2nd Approach)
Database System Concepts - 7th Edition 18.27 ©Silberschatz, Korth and Sudarshan
Deadlock Handling(Cont.)
Timeout-Based Schemes:
• A transaction waits for a lock only for a specified amount of time. After
that, the wait times out and the transaction is rolled back.
• Ensures that deadlocks get resolved by timeout if they occur
• Simple to implement
• But may roll back transaction unnecessarily in absence of deadlock
Difficult to determine good value of the timeout interval.
• Starvation is also possible
Database System Concepts - 7th Edition 18.28 ©Silberschatz, Korth and Sudarshan
Deadlock Detection
Wait-for graph
• Vertices: transactions
• Edge from Ti Tj. : if Ti is waiting for a lock held in conflicting mode
byTj
The system is in a deadlock state if and only if the wait-for graph has a
cycle.
Invoke a deadlock-detection algorithm periodically to look for cycles.
Database System Concepts - 7th Edition 18.29 ©Silberschatz, Korth and Sudarshan
Deadlock Recovery
Selection of a victim
Rollback
Starvation
Database System Concepts - 7th Edition 18.30 ©Silberschatz, Korth and Sudarshan
Deadlock Recovery
Selection of a victim
Database System Concepts - 7th Edition 18.31 ©Silberschatz, Korth and Sudarshan
Deadlock Recovery
Rollback
• determine how far to roll back transaction
Total rollback: Abort the transaction and then restart it.
Partial rollback: Roll back victim transaction only as far as
necessary to release locks that another transaction in cycle is
waiting for
Database System Concepts - 7th Edition 18.32 ©Silberschatz, Korth and Sudarshan
Multiple Granularity
Database System Concepts - 7th Edition 18.33 ©Silberschatz, Korth and Sudarshan
Example of Granularity Hierarchy
Database System Concepts - 7th Edition 18.34 ©Silberschatz, Korth and Sudarshan
Multiple Granularity(Intention Lock Modes)
In addition to S and X lock modes, there are three additional lock modes
with multiple granularity:
• intention-shared (IS): indicates explicit locking at a lower level of the
tree but only with shared locks.
• intention-exclusive (IX): indicates explicit locking at a lower level with
exclusive or shared locks
• shared and intention-exclusive (SIX): the subtree rooted by that
node is locked explicitly in shared mode and explicit locking is being
done at a lower level with exclusive-mode locks.
Intention locks allow a higher level node to be locked in S or X mode
without having to check all descendent nodes.
Database System Concepts - 7th Edition 18.35 ©Silberschatz, Korth and Sudarshan
Why Intention Lock Modes?
Database System Concepts - 7th Edition 18.36 ©Silberschatz, Korth and Sudarshan
Why Intention Lock Modes?
Database System Concepts - 7th Edition 18.38 ©Silberschatz, Korth and Sudarshan
Compatibility Matrix with Intention Lock Modes
Database System Concepts - 7th Edition 18.39 ©Silberschatz, Korth and Sudarshan
Multiple Granularity Locking Protocol
Database System Concepts - 7th Edition 18.40 ©Silberschatz, Korth and Sudarshan
Multiple Granularity Locking Protocol
Database System Concepts - 7th Edition 18.41 ©Silberschatz, Korth and Sudarshan
Multiple Granularity
Ensures Serializability
This protocol enhances concurrency and reduces lock overhead.
It is particularly useful in applications that include a mix of
• Short transactions that access only a few data items
• Long transactions that produce reports from an entire file or set of
files
Deadlock is possible in the protocol as it is in the two-phase locking
protocol.
Database System Concepts - 7th Edition 18.42 ©Silberschatz, Korth and Sudarshan
Insert/Delete Operations and Predicate Reads
Database System Concepts - 7th Edition 18.43 ©Silberschatz, Korth and Sudarshan
Phantom Phenomenon
Database System Concepts - 7th Edition 18.44 ©Silberschatz, Korth and Sudarshan
Insert/Delete Operations and Predicate Reads
Database System Concepts - 7th Edition 18.45 ©Silberschatz, Korth and Sudarshan
Handling Phantoms
Database System Concepts - 7th Edition 18.46 ©Silberschatz, Korth and Sudarshan
Index Locking To Prevent Phantoms
Database System Concepts - 7th Edition 18.47 ©Silberschatz, Korth and Sudarshan
Next-Key Locking to Prevent Phantoms
Database System Concepts - 7th Edition 18.48 ©Silberschatz, Korth and Sudarshan
Timestamp Based Concurrency Control
Database System Concepts - 7th Edition 18.49 ©Silberschatz, Korth and Sudarshan
Timestamp-Based Protocols
Database System Concepts - 7th Edition 18.50 ©Silberschatz, Korth and Sudarshan
Timestamp-Ordering Protocol
Database System Concepts - 7th Edition 18.51 ©Silberschatz, Korth and Sudarshan
Timestamp-Based Protocols (Cont.)
Database System Concepts - 7th Edition 18.52 ©Silberschatz, Korth and Sudarshan
Timestamp-Based Protocols (Cont.)
Database System Concepts - 7th Edition 18.53 ©Silberschatz, Korth and Sudarshan
Example of Schedule Under TSO
Database System Concepts - 7th Edition 18.54 ©Silberschatz, Korth and Sudarshan
Another Example Under TSO
Database System Concepts - 7th Edition 18.55 ©Silberschatz, Korth and Sudarshan
Correctness of Timestamp-Ordering Protocol
Database System Concepts - 7th Edition 18.56 ©Silberschatz, Korth and Sudarshan
Recoverability and Cascade Freedom
Solution 1:
• A transaction is structured such that its writes are all performed at the
end of its processing
• All writes of a transaction form an atomic action; no transaction may
execute while a transaction is being written
• A transaction that aborts is restarted with a new timestamp
Solution 2:
• Limited form of locking: wait for data to be committed before reading it
Solution 3:
• Use commit dependencies to ensure recoverability
Database System Concepts - 7th Edition 18.57 ©Silberschatz, Korth and Sudarshan
Thomas’ Write Rule
Database System Concepts - 7th Edition 18.58 ©Silberschatz, Korth and Sudarshan
Validation-Based Protocol
Idea:
Postpone writes to end of transaction
• Keep track of data items read/written by transaction
• Validation performed at commit time, detect any out-of-serialization
order reads/writes
Also called as optimistic concurrency control since transaction executes
fully in the hope that all will go well during validation
Database System Concepts - 7th Edition 18.59 ©Silberschatz, Korth and Sudarshan
Validation-Based Protocol
Database System Concepts - 7th Edition 18.60 ©Silberschatz, Korth and Sudarshan
Validation-Based Protocol (Cont.)
Database System Concepts - 7th Edition 18.61 ©Silberschatz, Korth and Sudarshan
Validation Test for Transaction Tj
If for all Ti with TS (Ti) < TS (Tj) either one of the following condition holds:
• finishTS(Ti) < startTS(Tj)
• startTS(Tj) < finishTS(Ti) < validationTS(Tj) and the set of data items
written by Ti does not intersect with the set of data items read by
Tj.
then validation succeeds and Tj can be committed.
Otherwise, validation fails and Tj is aborted.
Justification:
• First condition applies when execution is not concurrent
The writes of Tj do not affect reads of Ti since they occur after Ti
has finished its reads.
• If the second condition holds, execution is concurrent, Tj does not read
any item written by Ti.
Database System Concepts - 7th Edition 18.62 ©Silberschatz, Korth and Sudarshan
Schedule Produced by Validation
Database System Concepts - 7th Edition 18.63 ©Silberschatz, Korth and Sudarshan
Multiversion Concurrency Control
Database System Concepts - 7th Edition 18.64 ©Silberschatz, Korth and Sudarshan
Multiversion Schemes
Database System Concepts - 7th Edition 18.65 ©Silberschatz, Korth and Sudarshan
Multiversion Timestamp Ordering
Each data item Q has a sequence of versions <Q1, Q2,...., Qm>. Each
version Qk contains three data fields:
• Content -- the value of version Qk.
• W-timestamp(Qk) -- timestamp of the transaction that created (wrote)
version Qk
• R-timestamp(Qk) -- largest timestamp of a transaction that
successfully read version Qk
Database System Concepts - 7th Edition 18.66 ©Silberschatz, Korth and Sudarshan
Multiversion Timestamp Ordering (Cont)
Database System Concepts - 7th Edition 18.67 ©Silberschatz, Korth and Sudarshan
Multiversion Timestamp Ordering (Cont)
Observations
• Reads always succeed
• A write by Ti is rejected if some other transaction Tj that (in the
serialization order defined by the timestamp values) should read Ti's
write, has already read a version created by a transaction older than
T i.
Protocol guarantees serializability
Database System Concepts - 7th Edition 18.68 ©Silberschatz, Korth and Sudarshan
Multiversion Two-Phase Locking
Database System Concepts - 7th Edition 18.69 ©Silberschatz, Korth and Sudarshan
Multiversion Two-Phase Locking (Cont.)
Read-only transactions
• are assigned a timestamp = ts-counter when they start execution
• follow the multiversion timestamp-ordering protocol for performing
reads
Do not obtain any locks
Read-only transactions that start after Ti increments ts-counter will see
the values updated by Ti.
Read-only transactions that start before Ti increments the
ts-counter will see the value before the updates by Ti.
Only serializable schedules are produced.
Database System Concepts - 7th Edition 18.70 ©Silberschatz, Korth and Sudarshan
MVCC: Implementation Issues
Database System Concepts - 7th Edition 18.71 ©Silberschatz, Korth and Sudarshan
Snapshot Isolation
Motivation: Decision support queries that read large amounts of data
have concurrency conflicts with OLTP transactions that update a few
rows
• Poor performance results
Solution 1: Use multiversion 2-phase locking
• Give logical “snapshot” of database state to read only transaction
Reads performed on snapshot
• Update (read-write) transactions use normal locking
• Works well, but how does system know a transaction is read only?
Solution 2 (partial): Give snapshot of database state to every transaction
• Reads performed on snapshot
• Use 2-phase locking on updated data items
• Problem: variety of anomalies such as lost update can result
• Better solution: snapshot isolation level (next slide)
Database System Concepts - 7th Edition 18.72 ©Silberschatz, Korth and Sudarshan
Snapshot Isolation
Database System Concepts - 7th Edition 18.73 ©Silberschatz, Korth and Sudarshan
Snapshot Read
Concurrent updates invisible to snapshot read
Database System Concepts - 7th Edition 18.74 ©Silberschatz, Korth and Sudarshan
Snapshot Write: First Committer Wins
• Variant: “First-updater-wins”
Check for concurrent updates when write occurs by locking item
But lock should be held till all concurrent transactions have
finished
(Oracle uses this plus some extra features)
Differs only in when abort occurs, otherwise equivalent
Database System Concepts - 7th Edition 18.75 ©Silberschatz, Korth and Sudarshan
Benefits of SI
Database System Concepts - 7th Edition 18.76 ©Silberschatz, Korth and Sudarshan
Snapshot Isolation
Database System Concepts - 7th Edition 18.77 ©Silberschatz, Korth and Sudarshan
Snapshot Isolation Anomalies
Database System Concepts - 7th Edition 18.78 ©Silberschatz, Korth and Sudarshan
Serializable Snapshot Isolation
Database System Concepts - 7th Edition 18.79 ©Silberschatz, Korth and Sudarshan
SI Implementations
Database System Concepts - 7th Edition 18.80 ©Silberschatz, Korth and Sudarshan
Working Around SI Anomalies
Can work around SI anomalies for specific queries by using select .. for
update (supported e.g. in Oracle)
• Example
select max(orderno) from orders for update
read value into local variable maxorder
insert into orders (maxorder+1, …)
select for update (SFU) clause treats all data read by the query as if it
were also updated, preventing concurrent updates
Can be added to queries to ensure serializability in many applications
• Does not handle phantom phenomenon/predicate reads though
Database System Concepts - 7th Edition 18.81 ©Silberschatz, Korth and Sudarshan
Weak Levels of Concurrency
Database System Concepts - 7th Edition 18.82 ©Silberschatz, Korth and Sudarshan
Weak Levels of Consistency
Database System Concepts - 7th Edition 18.83 ©Silberschatz, Korth and Sudarshan
Weak Levels of Consistency in SQL
Database System Concepts - 7th Edition 18.84 ©Silberschatz, Korth and Sudarshan
Concurrency Control across User Interactions
Database System Concepts - 7th Edition 18.85 ©Silberschatz, Korth and Sudarshan
Concurrency Control across User Interactions
Database System Concepts - 7th Edition 18.86 ©Silberschatz, Korth and Sudarshan
Advanced topics in Concurrency Control
Database System Concepts - 7th Edition 18.87 ©Silberschatz, Korth and Sudarshan
Online Index Creation
Database System Concepts - 7th Edition 18.88 ©Silberschatz, Korth and Sudarshan
Concurrency in Index Structures
Indices are unlike other database items in that their only job is to help in
accessing data.
Index-structures are typically accessed very often, much more than other
database items.
• Treating index-structures like other database items, e.g. by 2-phase
locking of index nodes can lead to low concurrency.
There are several index concurrency protocols where locks on internal
nodes are released early, and not in a two-phase fashion.
• It is acceptable to have nonserializable concurrent access to an index
as long as the accuracy of the index is maintained.
In particular, the exact values read in an internal node of a
B+-tree are irrelevant so long as we land up in the correct leaf
node.
Database System Concepts - 7th Edition 18.89 ©Silberschatz, Korth and Sudarshan
Concurrency in Index Structures (Cont.)
Database System Concepts - 7th Edition 18.90 ©Silberschatz, Korth and Sudarshan
Concurrency Control in Main-Memory Databases
Database System Concepts - 7th Edition 18.91 ©Silberschatz, Korth and Sudarshan
Latch-Free Data-structure Updates
Database System Concepts - 7th Edition 18.92 ©Silberschatz, Korth and Sudarshan
Latch-Free Data-structure Updates
Database System Concepts - 7th Edition 18.93 ©Silberschatz, Korth and Sudarshan
Latch-Free Data-structures (Cont.)
Consider:
delete latchfree(head) {
/* This function is not quite safe; see explanation in text. */
repeat
oldhead = head
newhead = oldhead−>next
result = CAS(head, oldhead, newhead)
until (result == success)
}
Above code is almost correct, but has a concurrency bug
• P1 initiates delete with N1 as head; concurrently P2 deletes N1 and
next node N2, and then reinserts N1 as head, with N3 as next
• P1 may set head as N2 instead of N3.
Known as ABA problem
See book for details of how to avoid this problem
Database System Concepts - 7th Edition 18.94 ©Silberschatz, Korth and Sudarshan
Concurrency Control with Operations
Database System Concepts - 7th Edition 18.95 ©Silberschatz, Korth and Sudarshan
Concurrency Control with Operations (Cont.)
Database System Concepts - 7th Edition 18.96 ©Silberschatz, Korth and Sudarshan
Real-Time Transaction Systems
Database System Concepts - 7th Edition 18.97 ©Silberschatz, Korth and Sudarshan
End of Chapter 18
Database System Concepts - 7th Edition 18.98 ©Silberschatz, Korth and Sudarshan