Assignment 3 -- Solution 1. Problem 1 H 1 : r 1 [y] r 1 [x] r 2 [x] w 1 [y] c 1 w 2 [y] c 2 H 1 is normally-strict two-phase locked: rl 1 [y] r 1 [y]

Slides:



Advertisements
Similar presentations
Database System Concepts 5 th Ed. © Silberschatz, Korth and Sudarshan, 2005 See for conditions on re-usewww.db-book.com Chapter 16 : Concurrency.
Advertisements

Database Systems (資料庫系統)
1 Lecture 11: Transactions: Concurrency. 2 Overview Transactions Concurrency Control Locking Transactions in SQL.
Concurrency II. Shared/Exclusive Locks Problem: while simple locks + 2PL guarantee conflict­serializability, they do not allow two readers of DB element.
Transaction Management: Concurrency Control CS634 Class 17, Apr 7, 2014 Slides based on “Database Management Systems” 3 rd ed, Ramakrishnan and Gehrke.
Cs4432concurrency control1 CS4432: Database Systems II Lecture #23 Concurrency Control Professor Elke A. Rundensteiner.
1 CS216 Advanced Database Systems Shivnath Babu Notes 12: Concurrency Control (II)
Concurrency Control Amol Deshpande CMSC424. Approach, Assumptions etc.. Approach  Guarantee conflict-serializability by allowing certain types of concurrency.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Concurrency Control Chapter 17 Sections
Lecture 11 Recoverability. 2 Serializability identifies schedules that maintain database consistency, assuming no transaction fails. Could also examine.
1 ICS 214B: Transaction Processing and Distributed Data Management Lecture 6: Cascading Rollbacks, Deadlocks, and Long Transactions Professor Chen Li.
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance.
Quick Review of Apr 29 material
Concurrent Transactions Even when there is no “failure,” several transactions can interact to turn a consistent state into an inconsistent state.
ICS 421 Spring 2010 Transactions & Concurrency Control (i) Asst. Prof. Lipyeow Lim Information & Computer Science Department University of Hawaii at Manoa.
Concurrency Control A.Sri Harsha Enforcing Serializability of Locks.
Concurrency Control and Recovery In real life: users access the database concurrently, and systems crash. Concurrent access to the database also improves.
©Silberschatz, Korth and Sudarshan16.1Database System Concepts 3 rd Edition Chapter 16: Concurrency Control Lock-Based Protocols Timestamp-Based Protocols.
Concurrency Control R&G - Chapter 17 Smile, it is the key that fits the lock of everybody's heart. Anthony J. D'Angelo, The College Blue Book.
Concurrency Control By Donavon Norwood Ankit Patel Aniket Mulye 1.
Concurrency. Busy, busy, busy... In production environments, it is unlikely that we can limit our system to just one user at a time. – Consequently, it.
Transaction Processing: Concurrency and Serializability 10/4/05.
Concurrency. Correctness Principle A transaction is atomic -- all or none property. If it executes partly, an invalid state is likely to result. A transaction,
©Silberschatz, Korth and Sudarshan16.1Database System Concepts 3 rd Edition Chapter 16: Concurrency Control Lock-Based Protocols Timestamp-Based Protocols.
Concurrency Control John Ortiz.
1 Concurrency Control. 2 Transactions A transaction is a list of actions. The actions are reads (written R T (O)) and writes (written W T (O)) of database.
© 1997 UW CSE 11/13/97N-1 Concurrency Control Chapter 18.1, 18.2, 18.5, 18.7.
Deadlock Characterization
08_Transactions_LECTURE2 DBMSs should guarantee ACID properties (Atomicity, Consistency, Isolation, Durability). This is typically done by guaranteeing.
Concurrency Control Lectured by, Jesmin Akhter, Assistant professor, IIT, JU.
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
Chapter 11 Concurrency Control. Lock-Based Protocols  A lock is a mechanism to control concurrent access to a data item  Data items can be locked in.
Concurrency control In production environments, it is unlikely that we can limit our system to just one user at a time. – Consequently, it is possible.
Chapter 15 Concurrency Control Yonsei University 1 st Semester, 2015 Sanghyun Park.
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance 3.6. Deadlock prevention.
1 Deadlocks 2 Resources Examples of computer resources –printers –tape drives –tables Processes need access to resources in reasonable order Suppose.
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance.
Operating Systems 软件学院 高海昌 Operating Systems Gao Haichang, Software School, Xidian University 22 Contents  1. Introduction** 
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance.
Transactions and Concurrency Control. Concurrent Accesses to an Object Multiple threads Atomic operations Thread communication Fairness.
Page 1 Concurrency Control Paul Krzyzanowski Distributed Systems Except as otherwise noted, the content of this presentation.
4/3/ Concurrency Control for Transactions Part One CSEP 545 Transaction Processing Philip A. Bernstein Copyright ©2003 Philip A. Bernstein.
1 Concurrency Control Lecture 22 Ramakrishnan - Chapter 19.
Transaction Management Overview. Transactions Concurrent execution of user programs is essential for good DBMS performance. – Because disk accesses are.
Concurrency Control Introduction Lock-Based Protocols
1 Concurrency control lock-base protocols timestamp-based protocols validation-based protocols Ioan Despi.
1/11/ Concurrency Control for Transactions Part One CSEP 545 Transaction Processing Philip A. Bernstein Copyright ©2012 Philip A. Bernstein.
1 Database Systems ( 資料庫系統 ) December 27, 2004 Chapter 17 By Hao-hua Chu ( 朱浩華 )
Timestamp-based Concurrency Control
Switch off your Mobiles Phones or Change Profile to Silent Mode.
Jinze Liu. ACID Atomicity: TX’s are either completely done or not done at all Consistency: TX’s should leave the database in a consistent state Isolation:
Academic Year 2014 Spring Academic Year 2014 Spring.
Assignment 6 - Solution Problem 1 Suppose a transaction sets an intention-write lock on a file and later sets a write lock on a record of the file. Is.
Sistem Operasi IKH311 Deadlock. 2 Resources Examples of computer resources printers tape drives tables Processes need access to resources in reasonable.
Transaction Management
Concurrency Control.
Part- A Transaction Management
Outline Introduction Background Distributed DBMS Architecture
Concurrency.
Lecture 21: Concurrency & Locking
Chapter 15 : Concurrency Control
ENFORCING SERIALIZABILITY BY LOCKS
Chapter 3 Deadlocks 3.1. Resource 3.2. Introduction to deadlocks
Lecture 22: Intro to Transactions & Logging IV
Chapter 3 Deadlocks 3.1. Resource 3.2. Introduction to deadlocks
Introduction to Deadlocks
Chapter 3 Deadlocks 3.1. Resource 3.2. Introduction to deadlocks
CONCURRENCY Concurrency is the tendency for different tasks to happen at the same time in a system ( mostly interacting with each other ) .   Parallel.
Database Systems (資料庫系統)
Database Systems (資料庫系統)
Presentation transcript:

Assignment 3 -- Solution 1

Problem 1 H 1 : r 1 [y] r 1 [x] r 2 [x] w 1 [y] c 1 w 2 [y] c 2 H 1 is normally-strict two-phase locked: rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] wl 1 [y] w 1 [y] c 1 ru 1 [x] wu 1 [y] wl 2 [y] w 2 [y] c 2 ru 2 [x] wu 2 [y] Note that ru 1 [y] isn’t needed, since ru 1 [y] was converted into wu 1 [y], i.e., T 1 holds only one lock on y. 2

H 2 : r 1 [y] r 1 [x] r 2 [x] w 2 [x] w 1 [y] c 1 w 2 [y] c 2 H 2 is two-phase locked, but not strict two-phase locked. To run w 2 [x], T 1 must have released its read lock on x before w 2 [x], which means it cannot be strict two-phase locked. Moreover, to be two- phase locked, it must have gotten its write lock on y before it released its read lock on x. Thus, we have the following: rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] wl 1 [y] ru 1 [x] wl 2 [x] w 2 [x] w 1 [y] c 1 wu 1 [y] wl 2 [y] w 2 [y] c 2 ru 2 [x] wu 2 [y] Problem 1 (continued) 3

H 3 : r 1 [y] r 1 [x] r 2 [x] w 1 [y] w 2 [y] c 2 c 1 H 3 is two-phase locked, but not strict two-phase locked because T 1 must have released its write lock before w 2 [y] executed. rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] wl 1 [y] w 1 [y] wu 1 [y] wl 2 [y] w 2 [y] c 2 ru 2 [x] wu 2 [y] c 1 ru 1 [x] Problem 1 (continued) 4

H 4 : r 1 [y] r 1 [x] r 2 [x] w 2 [x] r 3 [y] w 1 [y] c 1 w 3 [z] c 3 w 2 [y] c 2 H 4 is not two-phase locked. To see why, consider the following prefix of the history: rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] The next operation is w 2 [x]. So as in H 2, T 1 must have released its read lock on x before w 2 [x], so again the next few operations must have been wl 1 [y] ru 1 [x] wl 2 [x] w 2 [x], as in the following expanded prefix. rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] wl 1 [y] ru 1 [x] wl 2 [x] w 2 [x] Problem 1 (continued) 5

6 H 4 continued H 4 : r 1 [y] r 1 [x] r 2 [x] w 2 [x] r 3 [y] w 1 [y] c 1 w 3 [z] c 3 w 2 [y] c 2 rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] wl 1 [y] ru 1 [x] wl 2 [x] w 2 [x] The next operation is r 3 [y]. To have executed here, T 3 would have to obtain its lock on y, which requires that T 1 had already released its lock on y, which it could not have done at this point because it hasn’t yet executed w 1 [y]. Nevertheless, this history is SR. We have only the following SG edges: T 1  T 2 because (r 1 [x],w 2 [x]) and (w 1 [y], w 2 [y]) T 3  T 1 because (r 3 [y], w 1 [y]) There’s no cycle in the SG, so the history is serializable as T 3 T 1 T 2. Note that there are no transaction handshakes in the input, so there are none to preserve.

Extra credit: Is it possible for a history to be strict two-phase locked but not normally-strict two phase locked? No. To prove it, let H be a strict 2PL history that has been augmented with lock and unlock operations to demonstrate that it’s strict 2PL. We can transform H into a history each of whose lock operations immediately precedes the operation it’s synchronizing, as follows. Suppose that for some operation o i [x] in H, the corresponding lock request ol i [x] does not immediately precede o i [x]. The only constraint that prevents moving ol i [x] to the right in H so that it immediately precedes o i [x] is an unlock operation by T i, since that would break 2PL. However, since H is strict 2PL, all of T i ’s unlock operations follow c i. Therefore, it’s possible to move ol i [x] to the right in H so that it immediately precedes o i [x]. This can be done for all offending lock operations in H, thereby transforming it into a demonstration that H is normally-strict 2PL-ed. 7

Problem 2: Yes, a transaction can be involved in multiple deadlocks. Consider the following three sequential transactions: T 1 : r 1 [x] r 1 [y] T 2 : r 2 [x] r 2 [y] T 3 : w 3 [y] w 3 [x] Suppose they start executing as follows: H 1 : r 1 [x] r 2 [x] w 3 [y] So far, T 1 and T 2 each have a read lock on x, and T­ ­3 has a write lock on y. Next, each transaction tries to set a lock for its second operation: r 1 [y], r 2 [y], and w 3 [x]. However, no matter which order the three lock requests are made, none of those lock requests can be granted, because another transaction already owns a conflicting lock. In terms of the waits-for graph, we have: T 1  T 3 because T 1 requests a read lock on y and T 3 owns a write lock on y T 2  T 3 for the same reason as above T 3  T 1 because T 3 requests a write lock on x and T 1 owns a read lock on x T 3  T 2 for the same reason as above. Thus, there are two deadlock cycles in the graph, T 1  T 3  T 1 and T 2  T 3  T 2. 8

Since each transaction is sequential, it can only have one blocked operation. It is therefore tempting to say that there could only be one outgoing edge from the transaction in the waits-for graph. But the italicized implication is wrong, because a transaction may issue a write request, thereby waiting for all of the transactions holding a read lock. Therefore, it is waiting for each of those read transactions and has more than one outgoing edge. In the above example T 3 is waiting for both T 1 and T 2 to unlock x. Then T 1 and T 2 each request a lock on y, which causes each of them to deadlock (independently) with T 3. Problem 2 (continued): 9

Problem 3 Let’s hand execute each sequence by issuing a lock request for each operation as it arrives: a) H 1 : r 1 [x,y] r 2 [x] w 1 [x] w 2 [z] r 3 [z] r 3 [y] w 3 [y] rl 1 [x,y] r 1 [x,y] rl 2 [x] r 2 [x] {wl 1 [x] is blocked} wl 2 [z] w 2 [z] {T 2 is done so it could have issued commit at this point} c 2 wu 2 [x] wu 2 [z] {now we can set wl 1 [x]} wl 1 [x] w 1 [x] {T 1 is done so it can commit} c 1 ru 1 [y] wu 1 [x] {now there are no locks held so T 3 can execute and commit}. So adding commits to H 1 : H 1 : r 1 [x,y] r 2 [x] w 1 [x] w 2 [z] c 2 c 1 r 3 [z] r 3 [y] w 3 [y] c 3 10

b) H 2 : r 1 [x,y] r 2 [x] w 1 [x] r 3 [z] w 2 [z] r 3 [y] w 3 [y] rl 1 [x,y] r 1 [x,y] rl 2 [x] r 2 [x] {w 1 [x] is blocked} rl 3 [z] r 3 [z] {w 2 [z] is blocked} rl 3 [y] r 3 [y] {w 3 [y] is blocked} There’s a deadlock: w 1 [x] is waiting for rl 2 [x], w 2 [z] is waiting for rl 3 [z], and w 3 [y] is waiting for rl 1 [y]. Problem 3 (continued) 11