1Database Tuning, Spring 2007
Lecture 7:Concurrency control
Rasmus Pagh
2Database Tuning, Spring 2007
Today’s lecture
• Concurrency control basics• Conflicts and serializability• Locking• Isolation levels in SQL• Optimistic concurrency control• Transaction tuning• Transaction chopping
3Database Tuning, Spring 2007
Problem session
• Come up with examples of undesiredbehaviour that could occur if severaltransactions run in parallel such thatthe actions interleave. Consider e.g.:– Transferring money and adding interest in
a bank’s database.– Booking plane tickets.
4Database Tuning, Spring 2007
ACID properties of transactions
• Atomicity: A transaction is executedeither completely or not at all.
• Consistency: Database constraintsmust be kept.
• Isolation: Transactions must appear toexecute one by one in isolation.
• Durability: The effect of a committedtransaction must never be lost.
5Database Tuning, Spring 2007
Today: Atomicity and isolation
• This lecture is concerned with atomicityand isolation.
• Durability: Read RG 18, or SB 2.3• Consistency is a consequence of
atomicity and isolation + maintainingany declared DB constraint (notdiscussed in this course).
6Database Tuning, Spring 2007
Isolation and serializability
• We would like the DBMS to maketransactions satisfy serializability:– The state of the database should always
look as if the committed transactions wereperformed one by one in isolation (i.e., in aserial schedule).
• The scheduler of the DBMS is allowedto choose the order of transactions:– It is not necessarily the transaction that is
started first, which is first in the serialschedule.
– The order may even look different from theviewpoint of different users.
7Database Tuning, Spring 2007
A simple scheduler
• A simple scheduler would maintain aqueue of transactions, and carry themout in order.
• Problems:– Transactions have to wait for each other,
even if unrelated (e.g. requesting data ondifferent disks).
– Smaller throughput. (Why?)– Some transactions may take very long, e.g.
when external input or remote data isneeded during the transaction.
8Database Tuning, Spring 2007
Interleaving schedulers
• Good DBMSs have schedulers thatallow the actions of transactions tointerleave.
• However, the result should be as ifsome serial schedule was used.
• Such schedules are called serializable.• In practice schedulers do not recognize
all serializable schedules, but allow justsome.Next: Conflict serializable schedules.
9Database Tuning, Spring 2007
Simple view on transactions
• We regard a transaction as a sequenceof reads and writes of DB elements,that may interleave with sequences ofother transactions.
• DB elements could be e.g. a value in atuple, an entire tuple, or a disk block.
• rT(X), shorthand for ”transaction Treads database element X”.
• wT(X), shorthand for ”transaction Twrites database element X”.
10Database Tuning, Spring 2007
Conflicts
• The order of some operations is of noimportance for the final result ofexecuting the transactions.
• Example: We may interchange theorder of any two read operationswithout changing the behaviour of thetransaction(s) doing the reads.
• In other cases, changing the order maygive a different result - there is aconflict.
11Database Tuning, Spring 2007
What operations conflict?
• By considering all cases, it can be seenthat two operations can conflict only if:– They involve the same DB element, and– At least one of them is a write operation.
• Note that this is a conservative (butsafe) rule.
rT2(A)rT2(A)
wT1(A)rT1(A)
12Database Tuning, Spring 2007
Conflict serializability
• Suppose we have a schedule for theoperations of several transactions.
• We can obtain conflict-equivalentschedules by swapping adjacentoperations that do not conflict.
• If a schedule is conflict-equivalent to aserial schedule, it is serializable.
• The converse is not true (ex. in RG).
13Database Tuning, Spring 2007
Testing conflict serializability
• Suppose we have a schedule for theoperations of current transactions.
• If there is a conflict between operationsof two transactions, T1 and T2, weknow which of them must be first in aconflict-equivalent serial schedule.
• This can be represented as a directededge in a graph with transactions asvertices.
14Database Tuning, Spring 2007
Problem session
• Find a criterion on the precedence graphwhich is equivalent to conflict-serializability:– If the graph meets the criterion the schedule is
conflict-serializable, and– If the schedule is conflict-serializable, the graph
meets the criterion.
15Database Tuning, Spring 2007
Enforcing serializability
• Knowing how to recognize conflict-serializability is not enough.
• We will now study mechanisms thatenforce serializability:– Locking (pessimistic concurrency control).– Time stamping (optimistic concurrency
control).
16Database Tuning, Spring 2007
Locks
• In its simplest form, a lock is a right toperform operations on a databaseelement.
• Only one transaction may hold a lockon an element at any time.
• Locks must be requested bytransactions and granted by the lockingscheduler.
17Database Tuning, Spring 2007
Two-phase locking
• Commercial DBMSs widely use two-phase locking, satisfying the condition:– In a transaction, all requests for locks
precede all unlock requests.
• If two-phase locking is used, theschedule is conflict-equivalent to aserial schedule in which transactionsare ordered according to the time oftheir first unlock request. (Why?)
18Database Tuning, Spring 2007
Strict two-phase locking
• In strict 2PL all locks are releasedwhen the transaction completes.
• This is commonly implemented incommercial systems, since:– it makes transaction rollback easier to
implement, and– avoids so-called cascading aborts (this
happens if another transaction reads avalue by a transaction that is later rolledback)
19Database Tuning, Spring 2007
Lock modes
• The simple locking scheme we saw istoo restrictive, e.g., it does not allowdifferent transactions to read the sameDB element concurrently.
• Idea: Have several kinds of locks,depending on what you want to do.Several locks on the same DB elementmay be ok (e.g. two read locks).
20Database Tuning, Spring 2007
NoNoX
NoYesSLock held
XS
Lock requested
Shared and exclusive locks
• Locks for reading can be shared (S).• Locks needed for writing must be
exclusive (X).• Compatibility matrix says which locks
are granted:
21Database Tuning, Spring 2007
Update locks
• A transaction that will eventually writeto a DB element, may allow other DBelements to keep read locks until it isready to write.
• This can be achieved by a specialupdate lock (U) which can be upgradedto an exclusive lock.
22Database Tuning, Spring 2007
NoNoNoX
No
No
X
NoNo (!)U
YesYesSLock held
US
Lock requested
Compatibility for update locks
• Question: Why not upgrade sharedlocks?
23Database Tuning, Spring 2007
The locking scheduler
• The locking scheduler is responsible forgranting locks to transactions.
• It keeps lists of all currents locks, andof all current lock requests.
• Locks are not necessarily granted insequence, e.g., a request may have towait until another transaction releasesits lock.
• Efficient implementation not discussedin this lecture.
24Database Tuning, Spring 2007
Problem session
• So far we did not discuss what DBelements to lock: Atomic values, tuples,blocks, relations?
• What are the advantages anddisadvantages of fine-grained locks(such as locks on tuples) and coarse-grained locks (such as locks onrelations)?
• Explain the following advice from SB:”Long transactions should use tablelocks, short transactions should userecord locks”.
25Database Tuning, Spring 2007
Granularity of locks
• Fine-grained locks allow a lot ofconcurrency, but may cause problemswith deadlocks.
• Coarse-grained locks require fewerresources by the locking scheduler.
• We want to allow fine-grained locks,but use (or switch to) coarser lockswhen needed.
• Some DBMSs switch automatically -this is called lock escalation. Thedownside is that this easily leads todeadlocks.
26Database Tuning, Spring 2007
Multiple-granularity locking
• An exclusive lock on a tuple shouldprevent an exclusive lock on the wholerelation.
• To implement this, all locks must beaccompanied by intention locks athigher levels of the hierarchy ofdatabase elements.
• We denote shared/exclusive intentionlocks by IS/IX, where I stands for theintention to shared/exclusively lockdatabase elements at a lower level.
27Database Tuning, Spring 2007
No
No
No
No
X
NoNoNoX
NoYesYesIX
No
Yes
IX
YesYesS
YesYesIS
Lock held
SIS
Lock requested
Compatibility of intention locks
28Database Tuning, Spring 2007
Locks on indexes
• When updating a relation, any indexeson the table also need to be updated.
• Again, we must use locks to ensureserializability.
• B-trees have a particular challenge:The root may be changed by anyupdate, so it seems concurrent updatescan’t be done using locks.
29Database Tuning, Spring 2007
Locks in B-trees
• First idea:– Put an exclusive lock on a B-tree node if
there is a chance it may have to change.– Lock from top to bottom along the path.– Unlock from bottom to top as soon as
nodes have been updated.
• Refinement:– Get IX locks top-down on the search path.– Convert these to X locks top-down, as
needed.
30Database Tuning, Spring 2007
Phantom tuples
• Suppose we lock tuples where A=42 ina relation, and subsequently anothertuple with A=42 is inserted.
• For some transactions this may resultin unserializable behaviour, i.e., it willbe clear that the tuple was insertedduring the course of a transaction.
• Such tuples are called phantoms.
31Database Tuning, Spring 2007
Avoiding phantoms
• Phantoms can be avoided by putting anexclusive lock on a relation beforeadding tuples. (However, this givespoor concurrency.)
• A technique called index locking mayprevent other transactions frominserting phantom tuples, but allowmost non-phantom insertions.
• In SQL, the programmer may choose toeither allow phantoms in a transactionor insist they should not occur.
32Database Tuning, Spring 2007
Exercise (ADBT exam 2005)
33Database Tuning, Spring 2007
SQL isolation levels
• A transaction in SQL may be chosen tohave one of four isolation levels:– READ UNCOMMITTED:
”No locks are obtained.”– READ COMMITTED:
”Read locks are immediately released -read values may change during thetransaction.”
– REPEATABLE READ:”2PL but no lock when adding new tuples.”
– SERIALIZABLE:”2PL with lock when adding new tuples.”
34Database Tuning, Spring 2007
SQL isolation levels
NoNoNoSerializable
MaybeNoNoRepeatable read
MaybeMaybeNoRead committed
MaybeMaybeMaybeRead uncommitted
PhantomsUnrepeatableread
DirtyRead
Isolation Level
35Database Tuning, Spring 2007
SQL implementation
• Note that implementation is not part ofthe SQL standards - they specify onlysemantics.
• A DBMS designer may choose anotherimplementation than the mentionedlocking schemes, as long as thesemantics conforms to the standard.
36Database Tuning, Spring 2007
Cursor stability
• Most DBMSs extend the guarantee ofREAD COMMITTED with cursor stability:– “Read locks are held for the duration
of a single SQL statement.”–Still, values seen may change from
one statement to the next.
37Database Tuning, Spring 2007
Snapshot isolation
• Some DBMSs implement snapshotisolation, an isolation level that givesa stronger guarantee than READCOMMITTED.
• Each transaction T executes againstthe version of the data items that wascommitted “when the T started”.
• Possible implementation:–No locks for read, locks for writes.–Store old versions of data (costs
space).
38Database Tuning, Spring 2007
Locks and deadlocks
• The DBMS sometimes must make atransaction wait for another transactionto release a lock.
• This can lead to deadlock if e.g. A waitsfor B, and B waits for A.
• In general, we have a deadlock exactlywhen there is a cycle in the waits-forgraph.
• Deadlocks are resolved by abortingsome transaction involved in the cycle.
39Database Tuning, Spring 2007
Dealing with deadlocks
• Possibilities:– Examine the waits-for graph periodically to
find any deadlock.– If a transaction lived for too long it may be
involved in a deadlock - roll back.– Use timestamps, unique numbers
associated with every transaction toprevent deadlocks.
• Deadlocks are less likely if we lockentire relations - but this decreasesthroughput.
40Database Tuning, Spring 2007
Avoiding deadlocks by timestamp
• Two possible policies when T waits for U:– Wait-die.
If T is youngest it is rolled back.– Wound-wait.
If U is youngest it is rolled back.
• In both cases there can be no waits-forcycles, because transactions only waitfor younger (resp. older) transactions.
• Why always roll back the youngest?
41Database Tuning, Spring 2007
Summary of locking
• Locking can prevent transactions fromengaging in non-serializable behaviour.
• However, it is sometimes a bit too strictand pessimistic, not allowing as muchconcurrency as we would like.
• Next we will consider optimisticconcurrency control that works wellwhen transactions don’t conflict much.
42Database Tuning, Spring 2007
Optimistic concurrency control
• Basic idea: Let transactions go ahead,and only at the end make sure that thebehavior is serializable.
• Several ways of realizing:– Validation– Optimistic 2PL (private workspace)– Timestamping (next)
43Database Tuning, Spring 2007
Timestamps
• Idea: Associate a unique number, thetimestamp, with each transaction.
• Transactions should behave as if theywere executed in order of theirtimestamps.
• For each database element, record:• The highest timestamp of a transaction that read
it.• The highest timestamp of a transaction that
wrote it.• Whether the writing transaction has committed.
44Database Tuning, Spring 2007
Timestamp based scheduling
• If transaction T requests to:– Read a DB element written by an
uncommitted transaction, it must wait for itto commit or abort.
– Read a DB element with a higher writetimestamp, T must be rolled back.
– Write a DB element with a higher readtimestamp, T must be rolled back.
• Rolling back means undoing all actions,getting a new timestamp, andrestarting.
45Database Tuning, Spring 2007
Problem session
• What should the scheduler do if atransaction requests to write a DBelement with a higher write timestamp?
46Database Tuning, Spring 2007
Multiversion timestamps
• In principle, all previous versions of DBelements could be saved.
• This would allow any read operation tobe consistent with the timestamp of thetransaction.
• Used in many systems for schedulingread only transactions. (In practice,only recent versions are saved.)
47Database Tuning, Spring 2007
Optimism vs pessimism
• Pessimistic concurrency is best in high-conflict situations:– Smallest number of aborts.– No wasted processing (if no deadlocks).
• Optimistic concurrency control is best ifconflicts are rare, e.g., if there aremany read-only transactions.– Highest level of concurrency.– Time stamp methods used in some
distributed databases.
48Database Tuning, Spring 2007
Lock tuning
• SB offers this advice on locking:– Use special facilities for long reads.– Eliminate locking when unnecessary.– Use the weakest isolation guarantee the
application allows.– Change the database schema only during
”quiet periods” (catalog bottleneck).– Think about partitioning.– Select the appropriate granularity of
locking. (Next)– If possible, chop transactions into smaller
pieces. (Later)
49Database Tuning, Spring 2007
Locking in Oracle
• ”Oracle Database always performs necessary locking toensure data concurrency, integrity, and statement-levelread consistency. You can override these default lockingmechanisms. For example, you might want to override thedefault locking of Oracle Database if:– You want transaction-level read consistency or "repeatable reads"
- where transactions query a consistent set of data for the durationof the transaction, knowing that the data has not been changed byany other transactions. This level of consistency can be achievedby using explicit locking, read-only transactions, serializabletransactions, or overriding default locking for the system.
– A transaction requires exclusive access to a resource. To proceedwith its statements, the transaction with exclusive access to aresource does not have to wait for other transactions to complete.”
50Database Tuning, Spring 2007
Locking in Oracle, cont.
• Locking a table T:
LOCK TABLE T IN EXCLUSIVE MODE;
• Unlocking all locked tables:
commit;
• Other lock modes are also available.
51Database Tuning, Spring 2007
Transaction tuning example
Simple purchases:• Purchase item I for price P
– 1. If cash < P then roll back transaction(constraint)
– 2. Inventory(I) := inventory(I)+P– 3. Cash := Cash – P
• Two purchase transactions P1 and P2– P1 has item I for price 50– P2 has item I for price 75– Cash is 100
(slide (c) Shasha and Bonnet, 2001)
52Database Tuning, Spring 2007
Example: Simple Purchases
• If 1-2-3 as one transaction then one ofP1, P2 rolls back.
• If 1, 2, 3 as three distinct transactions:– P1 checks that cash > 50. It is.– P2 checks that cash > 75. It is.– P1 completes. Cash = 50.– P2 completes. Cash = - 25.
(slide (c) Shasha and Bonnet, 2001)
53Database Tuning, Spring 2007
Example: Simple Purchases
• Orthodox solution– Make whole program a single transaction
• Cash becomes a bottleneck!
• Chopping solution– Find a way to rearrange and then chop up
the transactions without violatingserializable isolation level.
(slide (c) Shasha and Bonnet, 2001)
54Database Tuning, Spring 2007
Example: Simple Purchases
• Chopping solution:– 1. If Cash < P then roll back.
Cash := Cash – P.– 2. Inventory(I) := inventory(I) + P
• Chopping execution:– P11: 100 > 50. Cash := 50.– P21: 75 > 50. Rollback.– P12: inventory := inventory + 50.
(slide (c) Shasha and Bonnet, 2001)
55Database Tuning, Spring 2007
Transaction Chopping
• Execution rules:– When pieces execute, they follow the
partial order defined by the transactions.– If a piece is aborted because of a conflict, it
will be resubmitted until it commits– If a piece is aborted because of an abort,
no other pieces for that transaction willexecute.
(slide (c) Shasha and Bonnet, 2001)
56Database Tuning, Spring 2007
Transaction Chopping
• Let T1, T2, …, Tn be a set oftransactions. A chopping partitionseach Ti into pieces ci1, ci2, …, cik.
• A chopping of T is rollback-safe if– (a) T does not contain any abort commands
or– (b) if the abort commands are in the first
piece.
(slide (c) Shasha and Bonnet, 2001)
57Database Tuning, Spring 2007
Summary
• Concurrency control is crucial in aDBMS.
• Handling CC problems requires anunderstanding of the involvedmechanisms.
• Mostly, the schedule of operations oftransactions should be serializable.
• The scheduler may use locks ortimestamps.– Locks allow less concurrency, and may
cause deadlocks.– Timestamps may cause more aborts.
58Database Tuning, Spring 2007
Exercise
ADBT exam 2006, problem 4