©Silberschatz, Korth and Sudarshan15.1Database System Concepts - 6 th Edition Concurrency Control...

©Silberschatz, Korth and Sudarshan15.1Database System Concepts - 6th Edition

Concurrency ControlConcurrency Control

Introduction

Lock-Based Protocols

Timestamp-Based Protocols


The Two-Phase Locking ProtocolThe Two-Phase Locking Protocol

This is a protocol which ensures conflict-serializable schedules.

Phase 1: Growing Phase

transaction may obtain locks

transaction may not release locks

Phase 2: Shrinking Phase

transaction may release locks

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


3

Two-Phase Locking (2PL)Two-Phase Locking (2PL)

Rule (1) Ti locks tuple A before read/write

Rule (2) If Ti holds the lock on A, no other transaction is

granted the lock on A

Rule (3): Growing stage: Ti may obtain locks, but may not

release any lock

Shrinking stage: Ti my release locks, but may not obtain any new locks


4

# locks

held by

Ti

Time

Growing Shrinking

Phase Phase

Two-Phase LockingTwo-Phase Locking


Pitfalls of 2PL and Pitfalls of 2PL and many locking protocolsmany locking protocols

Deadlocks is possible with basic 2PL.

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.

Example T1 needs A, T2 needs B, but T3 needs both A and B.

Concurrency control manager can be designed to prevent starvation.

Non-recoverable schedules can occur while using basic 2PL

Restrictive forms of 2PL can be used to avoid these problems.


Non-recoverable ScheduleNon-recoverable Schedule

T2’s dirty read can not be undone since the transaction has committed


Recoverable ScheduleRecoverable ScheduleA schedule is recoverable, if every transaction that performs dirty reads commits after the transaction that wrote the dirty data.

S1 S2

• Which schedule is recoverable?• What is the cost of recovery?• Cascading of dirty data and of rollbacks.• How to ensure recoverability?• How to ensure recoverability without having to cascade?


8

# locks

held by

Ti

Time

Commit

Rigorous Two-Phase Locking (R2PL)Rigorous Two-Phase Locking (R2PL)

• Strict 2PL unlock x-locks only at the end of transaction• Rigorous 2PL releases X-locks & S-locks only at the end of transaction• As such they exclude dirty reads and produce recoverable cascadeless

schedules.


CheckpointCheckpoint

Rigorous 2PL guarantees recoverable cascadeless serializable schedule

But deadlocks can still occur: Handling deadlocks

1.Detection and recovery: using the

2.Deadlock prevention in 2PL: can be made deadlock-free by using

Conservative 2PL

wait-die scheme

wound-wait scheme

Lock-free Protocols such as timestamp-based scheduling do not have the deadlock problem.


10

# locks

held by

Ti

Time Commit

Conservative Two-Phase Locking Conservative Two-Phase Locking

Our transaction requests all the locks at the beginning,If it does not get them it does not start. If it gets the resources and starts it will complete.


Deadlock Detection and Recovery:Deadlock Detection and Recovery:the wait-for graphthe wait-for graph

Deadlocks can be described as a wait-for graph, which consists of a pair G = (V,E),

V is a set of Transactions

E is a set of arcs between transactions: A B

A B if A is waiting for B to release a lock on some data item.

Theorem: The system is in a deadlock state if and only if the wait-for graph has a cycle.


Deadlock Detection & Recovery (cont.)Deadlock Detection & Recovery (cont.)

A. Keep the wait-for graph and periodically check it to see if there is a cycle.

When a deadlock is detected, select a transaction from each deadlock cycle and abort it.

B. Timeout Approach: If some transaction has failed to make any progress for a significant time, assume that this is because it is in a deadlock cycle and abort it.

Both these approaches are prone to starvation. E.g. a transaction with lots of conflicts might be delayed for a long time under both scheme A and B.


Deadlock RecoveryDeadlock Recovery

When deadlock is detected :

Some transaction will have to rolled back (made a victim) to break deadlock. Select that transaction as victim that will incur minimum cost.

Rollback -- determine how far to roll back transaction

Total rollback: Abort the transaction and then restart it.

More effective to roll back transaction only as far as necessary to break deadlock.

Starvation happens if same transaction is always chosen as victim factor to avoid starvation. Consider age or the number of previous rollbacks before rolling back a given transaction.


Deadlock PreventionDeadlock Prevention

2PL can also be made deadlock-free by adding additional constraints:

Conservative 2PL

wait-die scheme

wound-wait

Note: Protocols that do not use locks, e.g. timestamp-based scheduling do not have the deadlock problem


Timestamp Based Deadlock PreventionTimestamp Based Deadlock PreventionUsing transaction timestamps for the sake of deadlock prevention alone.wait-die scheme

older transaction may wait for younger one to release data item. Younger transactions never wait for older ones; they are rolled back instead.

a transaction may die several times before acquiring needed data item

wound-wait scheme — preemptive older transaction wounds (forces rollback) of younger transaction

instead of waiting for it. Younger transactions may wait for older ones.

may be fewer rollbacks than wait-die scheme.

Rolled back transactions must keep their initial timestamps.


Deadlock prevention (Cont.)Deadlock prevention (Cont.)

Both in wait-die and in wound-wait schemes, a rolled back transactions is restarted with its original timestamp. Older transactions thus have precedence over newer ones, and starvation is hence avoided.

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.

thus deadlocks are not possible

simple to implement; but starvation is possible. Also difficult to determine good value of the timeout interval.


2PL: many complications2PL: many complications

But even conservative + rigorous

deliver good concurren




18

But even conservative + rigorous

Start Commit

2PL—many refinements needed 2PL—many refinements needed

• Often deliver good performance. Why?


Concurrency ControlConcurrency Control

Introduction




Timestamp-Based ProtocolsTimestamp-Based Protocols

Each transaction is issued a timestamp when it enters the system. If an old transaction Ti has time-stamp TS(Ti), a new transaction Tj is assigned time-

stamp TS(Tj) such that TS(Ti) <TS(Tj).

The protocol manages concurrent execution such that the time-stamps determine the serializability order.

In order to assure such behavior, the protocol maintains for each data Q two timestamp values:

W-timestamp(Q) is the largest time-stamp of any transaction that executed write(Q) successfully.

R-timestamp(Q) is the largest time-stamp of any transaction that executed read(Q) successfully.


Timestamp-Based Protocols (Cont.)Timestamp-Based Protocols (Cont.) The timestamp ordering protocol ensures that any conflicting read

and write operations are executed in timestamp order.

Suppose a transaction Ti issues a read(Q)

If TS(Ti) W-timestamp(Q), then Ti needs to read a value of Q that was already overwritten.

Hence, the read operation is rejected, and Ti is rolled back.

If TS(Ti) W-timestamp(Q), then the read operation is executed, and R-timestamp(Q) is set to max(R-timestamp(Q), TS(Ti)).


Timestamp-Based Protocols (Cont.)Timestamp-Based Protocols (Cont.)

Suppose that transaction Ti issues write(Q).

If TS(Ti) < R-timestamp(Q), then the value of Q that Ti is producing was needed previously, and the system assumed that that value would never be produced.

1. Hence, the write operation is rejected, and Ti is rolled back.

If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an obsolete value of Q.

1. Hence, this write operation is rejected, and Ti is rolled back.

Otherwise, the write operation is executed, and W-timestamp(Q) is set to TS(Ti).


Example Use of the ProtocolExample Use of the Protocol

A partial schedule for several data items for transactions withtimestamps 1, 2, 3, 4, 5


Correctness of Timestamp-Ordering ProtocolCorrectness of Timestamp-Ordering Protocol

The timestamp-ordering protocol guarantees serializability since all the arcs in the precedence graph are of the form:

Thus, there will be no cycles in the precedence graph Timestamp protocol ensures freedom from deadlock as no

transaction ever waits. But the schedule may not be cascade-free, and may not even be

recoverable.


ThomasThomas’’ Write Rule Write Rule

Modified version of the timestamp-ordering protocol in which obsolete write operations may be ignored under certain circumstances.

When Ti attempts to write data item Q, if TS(Ti) < W-timestamp(Q),

then Ti is attempting to write an obsolete value of {Q}.

Rather than rolling back Ti as the timestamp ordering protocol

would have done, this {write} operation can be ignored.

Otherwise this protocol is the same as the timestamp ordering protocol.

Thomas' Write Rule allows greater potential concurrency.

Allows some view-serializable schedules that are not conflict-

serializable.

©Silberschatz, Korth and Sudarshan15.1Database System Concepts - 6 th Edition Concurrency Control...

Documents

Transcript of ©Silberschatz, Korth and Sudarshan15.1Database System Concepts - 6 th Edition Concurrency Control...