lecture 7: concurrency control · –locking (pessimistic concurrency control). –time stamping...

1Database Tuning, Spring 2007

Lecture 7:Concurrency control

Rasmus Pagh

Today’s lecture

• Concurrency control basics• Conflicts and serializability• Locking• Isolation levels in SQL• Optimistic concurrency control• Transaction tuning• Transaction chopping

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.

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.

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

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.

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.

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.

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

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.

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)

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

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.

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.

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

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

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

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)

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

NoYesSLock held

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:

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.

NoNoNoX

NoNo (!)U

YesYesSLock held

Lock requested

Compatibility for update locks

• Question: Why not upgrade sharedlocks?

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.

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

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.

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.

NoNoNoX

NoYesYesIX

YesYesS

YesYesIS

Lock held

Lock requested

Compatibility of intention locks

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.

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.

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.

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.

Exercise (ADBT exam 2005)

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

SQL isolation levels

NoNoNoSerializable

MaybeNoNoRepeatable read

MaybeMaybeNoRead committed

MaybeMaybeMaybeRead uncommitted

PhantomsUnrepeatableread

DirtyRead

Isolation Level

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.

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.

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

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.

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.

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?

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.

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)

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.

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.

Problem session

• What should the scheduler do if atransaction requests to write a DBelement with a higher write timestamp?

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

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.

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)

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

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.

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)

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.

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

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

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.

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.

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.

Exercise

ADBT exam 2006, problem 4

lecture 7: concurrency control · –locking (pessimistic concurrency control). –time stamping...

Documents

1 7. distributed concurrency control chapter 11 distributed...

jinze liu. tree-based concurrency control validation...

transparent concurrency control: decoupling concurrency...

concurrency and transaction processing. concurrency models...

goal of concurrency control concurrency control also called

choosing a concurrency model, optimistic or pessimistic

transaction & concurrency control 1. content 2 transactions...

concurrency control techniques chapter 18 concurrency...

graphical representation of pessimistic locking and...

chapter 9 concurrency control. contents concurrency control...

concurrency control wxes 2103 database. content concurrency...

goal of concurrency control concurrency control also

transactions and concurrency...

concurrency control

memory models concurrency control with shared optimistic...

transactions and concurrency control - freie...

revisiting optimistic and pessimistic concurrency...