Serializability

                                                                 Conflict serializable schedule orders an...
Precedence Graph and serializability                                     Example - Non-conflict serializable schedule

If ...
Exercise settings                                                          Exercise 1

• For this exercise you will work i...
Recoverable Schedule                                                                     Exercise 2
                      ...
Deadlock - an example                                               Deadlock - possible solutions?

                      ...
Recovery from Deadlock Detection                                            Exercise 3
                                   ...
Upcoming SlideShare
Loading in...5
×

Dbms serializability

36,713

Published on

Published in: Education
1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total Views
36,713
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
969
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

Dbms serializability

  1. 1. Serializability Conflict serializable schedule orders any conflicting operations in same way as some serial execution. Constrained write rule: transaction updates data item Practical session 1 based on its old value, which is first read. Thu 3/11/05 Under the constrained write rule we can use precedence graph to test for serializability. COMP 302 V. Tamma COMP 302 V. Tamma 22 Serializability - some important rules Precedence Graph In serializability, ordering of read/writes is important: Given a schedule S, a precedence graph is a directed (a) If two transactions only read a data item, they do not graph G= (N,E) where conflict and order is not important. • N = set of nodes (b) If two transactions either read or write completely • E = set of directed edges separate data items, they do not conflict and order is Created as follows: not important. • create a node for each transaction; (c) If one transaction writes a data item and another • a directed edge Ti → Tj, if Tj reads the value of an item reads or writes same data item, order of execution is written by Ti; important. • a directed edge Ti → Tj, if Tj writes a value into an item after it has been read by Ti. COMP 302 V. Tamma 20 COMP 302 V. Tamma 23
  2. 2. Precedence Graph and serializability Example - Non-conflict serializable schedule If an edge Ti → Tj exists in the precedence graph for S, then in any serial schedule S’ equivalent to S, Ti must appear before T j If the precedence graph contains cycle schedule is not conflict serializable. COMP 302 V. Tamma COMP 302 V. Tamma 24 View Serializability View Serializability Offers less stringent definition of schedule • Schedule is view serializable if it is view equivalent equivalence than conflict serializability. to a serial schedule. Two schedules S1 and S2 are view equivalent if: • Every conflict serializable schedule is view • For each data item x, if Ti reads initial value of x in S1, Ti must serializable, although converse is not true. also read initial value of x in S2. • It can be shown that any view serializable • For each read on x by Ti in S1, if value read by x is written by Tj, Ti must also read value of x produced by Tj in S2. schedule that is not conflict serializable contains • For each data item x, if last write on x performed by Ti in S1, one or more blind writes. same transaction must perform final write on x in S2. • In general, testing whether schedule is serializable is NP-complete. COMP 302 V. Tamma COMP 302 V. Tamma
  3. 3. Exercise settings Exercise 1 • For this exercise you will work in groups of 3 or 4 Consider the following schedule people Time T1 T2 T3 • You will have 10 minutes to work out the solution to the t1 begin_transaction t2 read (balx) begin_transaction problem with your colleagues t3 write (balx) write(balx) begin_transaction • After that, you will have 5 minutes to compare your t4 commit commit read(balx) solution with the one of your neighbours t5 commit Determine whether the schedule is conflict serialisable and/or view serialisable COMP 302 V. Tamma COMP 302 V. Tamma Solution ex 1 Recoverability The precedence graph looks like Serializability identifies schedules that maintain database consistency, assuming no transaction fails. Could also examine recoverability of transactions within schedule. If transaction fails, atomicity requires effects of transaction to be undone. • There is a cycle in the graph, therefore the schedule is NOT conflict serialisable Durability states that once transaction commits, its • T2 has a blind write, therefore the schedule is NOT view changes cannot be undone (without running another, serialisable compensating, transaction). COMP 302 V. Tamma COMP 302 V. Tamma 29
  4. 4. Recoverable Schedule Exercise 2 Consider the following schedule Time T1 T2 T3 A schedule where, for each pair of transactions Ti and Tj, t1 begin_transaction if Tj reads a data item previously written by Ti, then the t2 read (balx) begin_transaction t3 read (baly) read(baly ) begin_transaction commit operation of Ti precedes the commit operation t4 commit read(balx) write(balx) of Tj. t5 commit Determine if the schedule is: • conflict serialisable • view serialisable • recoverable • avoids abort cascading COMP 302 V. Tamma 30 COMP 302 V. Tamma Solution ex 2 Locking methods: problems The precedence graph looks like Deadlock: An impasse that may result when two (or more) transactions are each waiting for locks held by the other to be released. • The graph does not have a cycle thus the schedule is conflict serialisable • Since the schedule is conflict serialisable, then it is view serialisable • Recoverable; (however, does not avoid cascading abort if T3 had aborted, T2 would also have to abort as it has read the value of an aborted transaction). COMP 302 V. Tamma COMP 302 V. Tamma 45
  5. 5. Deadlock - an example Deadlock - possible solutions? Only one way to break deadlock: abort one or more of the transactions. Deadlock should be transparent to user, so DBMS should restart transaction(s). Two general techniques for handling deadlock: • Deadlock prevention. • Deadlock detection and recovery. COMP 302 V. Tamma 45 COMP 302 V. Tamma 46 Deadlock Prevention Deadlock Detection and Recovery DBMS looks ahead to see if transaction would cause DBMS allows deadlock to occur but recognizes it and deadlock and never allows deadlock to occur. breaks it. Could order transactions using transaction timestamps: Usually handled by construction of wait-for graph (WFG) • Wait-Die - only an older transaction can wait for younger showing transaction dependencies: one, otherwise transaction is aborted (dies) and restarted • Create a node for each transaction. with same timestamp. • Create edge Ti -> Tj , if Ti waiting to lock item locked by Tj. • Wound-Wait - only a younger transaction can wait for an older one. If older transaction requests lock held by younger Deadlock exists if and only if WFG contains cycle. one, younger one is aborted (wounded). WFG is created at regular intervals. COMP 302 V. Tamma 47 COMP 302 V. Tamma 49
  6. 6. Recovery from Deadlock Detection Exercise 3 • The locking information for several transactions is shown below. Produce a wait-for-graph (WFG) for the transactions and determine whether deadlock Several issues: exist • choice of deadlock victim; • how far to roll a transaction back; • avoiding starvation. COMP 302 V. Tamma COMP 302 V. Tamma Solution ex 3 The WFG looks like • The graph shows that there is a deadlock COMP 302 V. Tamma
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×