Last Lecture. More Concurrency. Concurrency So Far. In This Lecture. Serialisability. Schedules. Database Systems Lecture 15

Size: px

Start display at page:

Download "Last Lecture. More Concurrency. Concurrency So Far. In This Lecture. Serialisability. Schedules. Database Systems Lecture 15"

Griselda Perry
6 years ago
Views:

1 Last Lecture More Concurrency Database Systems Lecture 15 Concurrency Locks and resources Deadlock Serialisability Schedules of transactions Serial & serialisable schedules For more information: Connolly and Begg chapter 0 In This Lecture Concurrency So Far More Concurrency fun that you can shake a stick at: Serialisability Precedence graphs Two phase locking Protocols, Serialisability theorem Timestamping For more information Connolly and Begg chapter 0 e want to run transactions concurrently: Schedules Serial schedules Equivalence Correctness Serialisability To prevent some problems we use locking protocols: S-locks -locks Deadlock Deadlock detection Deadlock recovery Schedules A `schedule' is the actual execution sequence of two or more concurrent transactions. A schedule of two transactions and is `serialisable' if and only if executing this schedule has the same effect as either ; or ;. e like serialisable schedules! Serialisability emember if a schedule is serialisable we know it is going to be correct. (give us a consistent database as a result) In order to know that a particular transaction schedule is serialisable, we can draw a precedence graph. The schedule is said to be serialisable if and only if there are no cycles in the resulting diagram. 1

2 Precedence Graphs Precedence Graph To determine if a schedule is serialisable we use a precedence graph: Transactions are vertices of the graph Directional arcs are drawn between conflict operations The schedule will then be serialisable (and hence correct) if there are no cycles To draw one: 1) Draw a node for each transaction in the schedule ) For each pair of following ordered conflict operations in S, create a directional arc in the same order Ti Tj () () () () () () create arc Ti -> Tj create arc Ti -> Tj create arc Ti -> Tj Precedence Graph Example Precedence Graph Example must reads before writes must read before writes Lost update schedule: = rite() COMMIT = + rite() COMMIT A serial version of the transactions has the graph reads before writes = 5 rite() 5 COMMIT = + rite() COMMIT Two-Phase Locking Two-Phase Protocol The mere presence of locks does not guarantee serialisability. Locking only guarantees this if it is two phased. That is all locks that are going to be opened do so, before any are closed. If all transactions obey the `two-phase locking protocol', then all possible interleaved executions are guaranteed serialisable. The two-phase locking protocol: 1) lock-acquisition phase: Before operating on any item, a transaction must acquire at least a shared lock on that item. Thus no item can be accessed without first obtaining the correct lock. ) lock-release phase: After releasing a lock, a transaction must never go on to acquire any more locks.

3 PL Example Serialisability Theorem is two-phased - all of its locks are acquired before it releases any of them S-lock() -lock() Unlock() Unlock() S-lock() Unlock() -lock() Unlock() is not - it releases its lock on and then goes on to later acquire a lock on A schedule of two-phased transactions might not be deadlock free, but if it is Any schedule of two-phased transactions is conflict serialisable i.e. it gives us the same results as a serial version of the schedule, and hence is correct! Serialisability Theorem Similarities A schedule of twophased transactions is either conflict serialisable or results in deadlock This relationship is captured in the waitfor and precedence graphs ait-for graph A cycle indicates deadlock Precedence graph A cycle indicates the schedule is not conflict serilisable For two-phased transactions these are the same thing. Precedence graph Each transaction is a vertex Arcs from to if 1) reads before writes ) writes before reads 3) writes before writes ait-for Graph Each transaction is a vertex Arcs from to if 1) S-locks then tries to -lock it ) -locks then tries to S-lock it 3) -locks then tries to -lock it Example Example rite() T3 ead() T3 T3 T3 ait for graph T3 rite() T3 ead() T3 T3 reads after writes must go before T3 ait for graph T3 Precedence graph Precedence graph 3

4 Example Example rite() T3 ead() T3 T3 T3 reads after writes must go before T3 T3 ait for graph T3 rite() T3 ead() T3 T3 writes after reads must go before T3 ait for graph T3 Precedence graph Precedence graph Deadlock Prevention Deadlock Prevention Deadlock can still arise with PL Deadlock is less of a problem than an inconsistent DB e can detect and recover from deadlock It would be nice to avoid it altogether Conservative PL All locks must be acquired before the transaction starts Hard to predict what locks are needed Low lock utilisation - transactions can hold on to locks for a long time, but not use them much e impose an ordering on the resources Transactions must acquire locks in this order Transactions can be ordered on the last resource they locked This prevents deadlock: If T x is waiting for a resource from T y then that resource must come after all of T x s current locks All the arcs in the wait-for graph point forwards - no cycles Timestamping Timestamping e ve seen Transactions can be run concurrently using a variety of techniques: Two phase locking ait-for and precedence graphs Deadlock prevention An alternative is timestamping equires less overhead in terms of tracking locks or detecting deadlock Determines the order of transactions before they are executed Each transaction has a timestamp, TS, and if T x starts before T y then: TS(T x ) < TS(T y ) Can use the system clock or an incrementing counter to generate timestamps At any point in time each resource has two timestamps (), the largest timestamp of any transaction that has read (), the largest timestamp of any transaction that has written 4

5 Timestamp Protocol Timestamping Example Now If a transaction, T tries to read : And if a transaction T tries to write : Given and lets assume: If TS(T) < () T is rolled back and restarted with a later timestamp If TS(T) () then the read succeeds and we set () to be max((), TS(T)) If TS(T) < () or TS(T) < () then T is rolled back and restarted with a later timestamp. Otherwise the write succeeds and we set () to TS(T) The transactions make alternate operations Timestamps are allocated from a counter starting at 1 goes first 1 TS TS 1 1 TS 1 TS 1 5

6 TS 1 TS 1 TS 1 Uh oh. has a read Timestamp on it that is greater than s TS 1 rollback TS 3 TS 3 New timestamp 6

3 TS 3 3 3 TS 3 3 3 TS 3 3 3 3 TS 3 Timestamping Transaction Summary The protocol means that transactions with higher times take precedence: Equivalent to running transactions in order of their final

7 3 TS TS TS TS 3 Timestamping Transaction Summary The protocol means that transactions with higher times take precedence: Equivalent to running transactions in order of their final time values Transactions don t wait - no deadlock! Problems Long transactions might keep getting restarted by new transactions starvation. olls back old transactions, which may have done a lot of work ecovery Schedules Serialisability ACID Properties Concurrency Locking PL Deadlock Transaction Manager Timestamping 7

8 Next Lecture Database Security Aspects of security Access to databases Privileges and views Database Integrity View updating, Integrity constraints For more information Connolly and Begg chapters 6 and 19 8

More Concurrency. Database Systems Lecture 17 Natasha Alechina

More Concurrency. Database Systems Lecture 17 Natasha Alechina More Concurrency Database Systems Lecture 17 Natasha Alechina In This Lecture Deadlock detection Deadlock prevention Timestamping For more information Connolly and Begg chapter 20 Deadlocks A deadlock