0% found this document useful (0 votes)
78 views34 pages

Properties of Schedules

The document discusses properties of concurrency control schemes for databases. It covers lock-based concurrency control using locking protocols like two-phase locking (2PL) and strict 2PL. These protocols ensure serializable and recoverable schedules. Issues like deadlocks, anomalies from interleaved execution, and finer-grained locking approaches like index locking are also summarized.

Uploaded by

Pritam Gupta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
78 views34 pages

Properties of Schedules

The document discusses properties of concurrency control schemes for databases. It covers lock-based concurrency control using locking protocols like two-phase locking (2PL) and strict 2PL. These protocols ensure serializable and recoverable schedules. Issues like deadlocks, anomalies from interleaved execution, and finer-grained locking approaches like index locking are also summarized.

Uploaded by

Pritam Gupta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 34

Properties of schedules

38
Concurrency control schemes
 The DBMS must provide a mechanism that
will ensure all possible schedules are:
 serializable
 recoverable, and preferably cascadeless
 Concurrency control protocols ensure these
properties.

39
Lock-Based Concurrency Control
 Lock - associated with some object
 shared or exclusive
 Locking protocol - set of rules to be followed
by each transaction to ensure good
properties.

40
Lock Compatibility Matrix

Locks on a data item are granted based on a


lock compatibility matrix:
Mode of Data Item
None Shared Exclusive

Request mode { Shared


Exclusive Y
Y Y
N
N
N

When a transaction requests a lock, it must wait


(block) until the lock is granted

41
Transaction performing locking
T1

lock-X(A)
R(A)
W(A)
unlock(A)
lock-S(B)
R(B)
unlock(B)

42
Two-Phase Locking (2PL)
 Two-Phase Locking Protocol
 Each Xact must obtain a S (shared) lock on object
before reading, and an X (exclusive) lock on object
before writing.
 A transaction can not request additional locks
once it releases any locks.
• growing phase
• shrinking phase
Strict Two-Phase Locking (Strict 2PL)
 Strict Two-phase Locking Protocol:
 Each Xact must obtain a S (shared) lock on object
before reading, and an X (exclusive) lock on object
before writing.
 A transaction can not request additional locks
once it releases any locks.
 All X (exclusive) locks acquired by a transaction
must be held until completion (commit/abort).
Not admissible under 2PL

T1 T2
R(A)
W(A)
R(A)
W(A)
R(B)
W(B)
Commit
R(B)
W(B)
Commit
45
Lock-based protocols

 2PL ensures conflict serializability


 Transactions can be ordered by their end of
growing phase (called lock point)
 A 2PL schedule is equivalent to the serial
schedule where transactions ordered by lock
point order.
 Strict 2PL ensures conflict serializable and
cascadeless schedules
 Writers hold an X lock until they commit.
Schedule following strict 2PL
T1 T2
S(A)
R(A)
S(A)
R(A)
X(B)
R(B)
W(B)
Commit
X(C)
R(C)
W(C)
Commit
47
Lock Management

 Lock and unlock requests are handled by the lock


manager
 Lock table entry (for an object):
 Number of transactions currently holding a lock
 Type of lock held (shared or exclusive)
 Pointer to queue of lock requests
 Locking and unlocking have to be atomic operations
 Lock upgrade: transaction that holds a shared lock
can be upgraded to hold an exclusive lock
Deadlocks

 Deadlock: Cycle of transactions waiting for


locks to be released by each other.
 Tend to be rare in practice.
 Two ways of dealing with deadlocks:
 Deadlock prevention
 Deadlock detection
Deadlock

T1 T2
X(A) granted

X(B) granted

X(B) queued
X(A) queued

 Deadlock must be prevented or avoided.

50
Deadlock Detection

 Create a waits-for graph:


 Nodes are transactions
 There is an edge from Ti to Tj if Ti is waiting for Tj
to release a lock
 add edge when queueing a lock request,
 remove edge when granting lock request.
 Periodically check for cycles in the waits-for
graph
 Resolve by aborting a transaction on cycle,
releasing its locks.
Deadlock Detection (Continued)
T1 T2 T3 T4
S(A)
R(A)
X(B)
W(B)
S(B)
S(C)
R(C)
X(C)
X(B)
X(A)

T1 T2

T4 T3
Deadlock Prevention

 Assign priorities based on timestamps.


Assume Ti wants a lock that Tj holds. Two
policies are possible:
 Wait-Die: If Ti has higher priority, Ti waits for Tj;
otherwise Ti aborts
 Wound-wait: If Ti has higher priority, Tj aborts;
otherwise Ti waits
 If a transaction re-starts, make sure it has its
original timestamp (to avoid starvation of a
transaction).
Performance of Locking

 Lock-based schemes resolve conflicting


schedules by blocking and aborting
 in practice few deadlocks and relatively few
aborts
 most of penalty from blocking
 To increase throughput
 lock smallest objects possible
 reduce time locks are held
 reduce hotspots

54
Anomalies with Interleaved Execution

 Not all interleavings of operations are okay.


 Anomaly: two consistency-preserving
committed transactions that lead to an
inconsistent state.
 Types of anomalies:
 Reading Uncommitted Data (WR Conflicts)
“dirty reads”
 Unrepeatable Reads (RW Conflicts)
 Overwriting Uncommitted Data (WW Conflicts)

55
Reading Uncommitted Data
T1: Transfer T2: Interest
“Dirty Read” R(A)
W(A)
R(A)
Inconsistent result of A is W(A)
exposed to transaction T2
R(B)
W(B)
Commit
R(B)
W(B)
Commit 56
Unrepeatable Reads

T1 could see two values for A, T1 T2


although it has not changed A itself.
R(A)
R(A)
W(A)
Commit
R(A)
W(A)
Commit

57
Overwriting Uncommitted Data

T1 T2
W(A)
W(B)
W(B)
Commit
W(A)
Commit

58
Transaction support in SQL

 Transaction automatically started for


SELECT, UPDATE, CREATE
 Transaction ends with COMMIT or
ROLLBACK (abort)
 SQL 99 supports SAVEPOINTs which are
simple nested transactions

59
What should we lock?

T1 T2

SELECT S.rating, MIN(S.age) UPDATE Sailors(Name, Rating,


FROM Sailors S Age) VALUES (“Joe”, 8, 33)
WHERE S.rating = 8

 Coarse locking:
 T1 S-lock on Sailors;
 T2 X-lock on Sailors
 Finer-grained locking:
 T1 S-lock on all rows with rating=8;
 T2 X-lock on Joe’s tuple.
60
The Phantom Problem
T1 T2

SELECT S.rating, MIN(S.age) UPDATE Sailors(Name, Rating,


FROM Sailors S Age) VALUES (“Joe”, 8, 33)
WHERE S.rating = 8
T3

INSERT Sailors(Name, Rating,


Age) VALUES (“Mary”, 8, 18)

 Suppose T1 locks all existing rows with rating=8.


 Then T3 creates row and sets X-lock
 These locks don’t conflict; T1 could read different
results even though it did not modify them itself.

61
The Phantom Problem
 T1 locks all existing rows with rating=8.
 But a new row satisfying condition could be
inserted
 Phantom problem: A transaction retrieves a
collection of tuples and sees different results,
even though it did not modify the tuples itself.
 Conceptually: must lock all possible rows.
 Can lock entire table.
 Better, use index locking.

62
Data
Index
Index Locking
r=1
 If there is an index on the rating field using
Alternative (2), T1 should lock the index page
containing the data entries with rating = 8.
 If there are no records with rating = 8, T1 must
lock the index page where such a data entry would
be, if it existed!
 If there is no suitable index, T1 must lock all
pages, and lock the file/table to prevent new
pages from being added, to ensure that no
new records with rating = 8 are added.
Predicate Locking

 Grant lock on all records that satisfy some


logical predicate, e.g. age > 2*salary.
 Index locking is a special case of predicate
locking for which an index supports efficient
implementation of the predicate lock.
 In general, predicate locking has a lot of
locking overhead.
Specify isolation level

 General rules of thumb w.r.t. isolation:


 Fully serializable isolation is more expensive than
“no isolation”
• We can’t do as many things concurrently (or
we have to undo them frequently)
 For performance, we generally want to
specify the most relaxed isolation level that’s
acceptable
 Note that we’re “slightly” violating a correctness
constraint to get performance!

65
Specifying isolation level in SQL

SET TRANSACTION [READ WRITE | READ ONLY]


ISOLATION LEVEL [LEVEL];

LEVEL = SERIALIZABLE
REPEATABLE READ
Less isolation
READ COMMITTED
READ UNCOMMITED

The default isolation level is SERIALIZABLE

Locks sets of objects, avoids phantoms


66
REPEATABLE READ

 T reads only changes made by committed


transactions
 No value read/written by T is changed by
another transaction until T completes.

 Phantoms possible: inserts of qualifying


tuples not avoided.

Locks only individual objects

67
READ COMMITTED
 T reads only changes made by committed
transactions
 No value read/written by T is changed by
another transaction until T completes.
 Value read by T may be modified while T in
progress.
 Phantoms possible.

X locks on written objects, held to end


S locks on read objects, but released immediately.

68
READ UNCOMMITTED

 Greatest exposure to other transactions


 Dirty reads possible
 Can’t make changes: must be READ ONLY
 Does not obtain shared locks before reading
 Thus no locks ever requested.

69
Summary of Isolation Levels

Level Dirty Read Unrepeatable Read Phantoms

READ UN- Maybe Maybe Maybe


COMMITTED

READ No Maybe Maybe


COMMITTED

REPEATABLE No No Maybe
READ

SERIALIZABLE No No No

70
Summary
 Concurrency control and recovery are among the
most important functions provided by a DBMS.
 Users need not worry about concurrency.
 System guarantees nice properties: ACID
 This is implemented using a locking protocol

 Users can trade isolation for performance using SQL


commands

71

You might also like