Computer Science 425 Distributed Systems

1. Computer Science 425Distributed Systems Lecture 18 Concurrency Control Reading: Section 13.4

2. Example Transaction Banking transaction for a customer (ATM) Transfer $100 from saving to checking account; Transfer $200 from money-market to checking account; Withdraw $400 from checking account. Transaction: 1. savings.deduct(100) /* includes verification */ 2. checking.add(100) /* depends on success of 1 */ 3. mnymkt.deduct(200) /* includes verification */ 4. checking.add(200) /* depends on success of 3 */ 5. checking.deduct(400) /* includes verification */ 6. dispense(400) 7. commit

3. Properties of Transactions (ACID) • Atomicity: All or nothing • Consistency: starting in a consistent state, the transaction ends in a consistent state. • Isolation: Each transaction must be performed without interference from other transactions, i.e., the intermediate effects of a transaction must not be visible to other transactions. • Durability: After a transaction has completed successfully, all its effects are saved in permanent storage. • Data saved in a file will survive if the server process crashes. “To support failure atomicity and durability, objects must be recoverable” • Atomicity: store tentative object updates (for later undo/redo) • Durability: store entire results of transactions (all updated objects) to recover from permanent server crashes.

4. Client Client Client Client Client Transaction Processing Systems Objects Trans. Manager Object Manager Scheduler Objects Trans. Manager Object Manager Scheduler • Transaction Workspace • locking / unlocking req. • Protocol management • Subtrans Management Object Creation, lock recovery, destruction Concurrency Control

5. Non-serially equivalent interleaving of operations Conflicting Ops. Slide from Last Class Transaction T1 Transaction T2 x= a.read() a.write(20)y = b.read() b.write(30) b.write(x) z = a.read() x= a.read() a.write(20)z = a.read() b.write(x) y = b.read() b.write(30) Serially equivalent interleaving of operations (why?)

6. Concurrent Transactions • Transaction operations can run concurrently, provided “isolation” principle is not violated (same as interleaving ops.) • Concurrent operations must be consistent: • If trans.T has executed a read operation on object A, a concurrent trans. U must not write to A until T commits or aborts. • If trans, T has executed a write operation on object A, a concurrent U must not read or write to A until T commits or aborts. • How to implement this? • First cut: locks

7. Example: Concurrent Transactions • Exclusive Locks Transaction T1 Transaction T2 OpenTransaction() balance = b.getBalance() OpenTransaction() balance = b.getBalance() b.setBalance = (balance*1.1) a.withdraw(balance* 0.1) CloseTransaction() b.setBalance = (balance*1.1) c.withdraw(balance*0.1) CloseTransaction() Lock B WAIT on B … Lock A … UnLock B Lock B UnLock A Lock C UnLock B UnLock C

8. Conflict Prevention: Locking • Transaction managers set locks on objects they need. A concurrent trans. cannot access locked objects. • Two phase locking: • In the first (growing) phase, new locks are acquired, and in the second (shrinking) phase, locks are released. • A transaction is not allowed acquire any new locks, once it has released any one lock. • Strict two phase locking: • Locking is performed when the requests to read/write are about to be applied. • Unlocking is performed by the commit/abort operations of the transaction coordinator. • To prevent dirty reads and premature writes, a transaction waits for another to commit/abort • Use of separate read and write locks is more efficient than a single exclusive lock.

9. 2P Locking: Non-exclusive locks non-exclusivelock compatibility Lock already Lock requested set read write none OKOK read OKWAIT write WAIT WAIT • A read lock is promoted to a write lock when the transaction needs write access to the same object. • A read lock shared with other transactions’ read lock(s) cannot be promoted. Transaction waits for other read locks to be released. • Cannot demote a write lock to read lock during transaction – violates the 2P principle

10. Locking Procedure in Strict-2P Locking • When an operation accesses an object: • if the object is not already locked, lock the object & proceed. • if the object has a conflicting lock by another transaction, wait until object is unlocked. • if the object has a non-conflicting lock by another trans., share the lock & proceed. • if the object has a lower lock by the same transaction, • if the lock is not shared, promote the lock & proceed • else, wait until shared locks are released, then lock & proceed • When a transaction commits or aborts: • release all locks set by the transaction

11. Example: Concurrent Transactions • Non-exclusive Locks Transaction T1 Transaction T2 OpenTransaction() balance = b.getBalance() OpenTransaction() balance = b.getBalance() b.setBalance =balance*1.1 Commit R-Lock B R-Lock B Cannot Promote lock on B, Wait Promote lock on B …

12. T : top-level transaction T = openSubTransaction T = openSubTransaction 1 2 commit T : T : 1 2 openSubTransaction openSubTransaction openSubTransaction prov. commit abort T T : T : : 21 11 12 openSubTransaction prov. commit prov. commit prov. commit T : 211 prov.commit Nested Transactions

13. Locking of Nested Transactions • Each transaction (i.e., root) is a single entity that must not access partial effects of other transactions • Any lock obtained or inherited by a subtrans. is inherited by its parent upon provisional commit (PROV) of the subtrans. • Subtrans. in a transaction with same root must not access partial effects of each other • Parent subtrans cannot run concurrently with its children. • If a parent subtrans has a lock on an object, it retains the lock during the time that its child subtrans is executing. That is, a child subtrans can obtain temporary access of its parent’s locks (kind of like a “lease”) • Subtrans at the same level can run concurrently, but when they access the same objects, the locking scheme must serialize the access.

14. Lock Acquisition and Release in Nested Transactions • For a subtransaction to acquire a read lock, • No other active subtrans can have a write lock on the object, and the only retainers of a write lock are its ancestors. • For a subtransaction to acquire a write lock, • No other active subtrans can have a read/write lock on that object, and the only retainers of read/write locks on that object are its ancestors. • When a subtransaction commits, its locks are inherited by its parent, allowing the parent to retain the locks in the same mode as the child. • When a subtransaction aborts, its locks are discarded. If the parent already retains the locks, it continues to do so.

15. Example: Concurrent Transactions • What happens in the example below? Transaction T1 Transaction T2 OpenTransaction() balance = b.getBalance() OpenTransaction() balance = b.getBalance() b.setBalance =balance*1.1 b.setBalance=balance*1.1 R-Lock B R-Lock B Cannot Promote lock on B, Wait Cannot Promote lock on B, Wait … …

16. Deadlocks • Necessary conditions for deadlocks • Non-sharable resources (locked objects) • No preemption on locks • Hold & Wait or Circular Wait Held by Held by Wait for Held by W ... Wait for Wait for A A V T T U B B ... U Wait for Wait for Held by Held by Wait for Held by Hold & Wait Circular Wait

17. Strategies to Fight Deadlock • Deadlocks can be resolved by lock timeout (costly and open to false positives) • Deadlock Prevention: violate one of the necessary conditions for deadlock (from previous slide), e.g., lock all objects at transaction start only releasing all if any acquisition fails • Deadlock Avoidance: Have transactions declare max resources they will request, but allow them to lock at any time • Deadlock Detection: deadlocks can be detected, e.g., by using a wait-for graph, & then resolved by aborting one of the transactions in the cycle.

18. Transaction T Transaction U Operations Locks Operations Locks A write lock a.deposit(100); B write lock b.deposit(200) b.withdraw(100) a.withdraw(200); U waits for T’s waits for ’s lock on B lock on A (timeout elapses) T’s lock on A becomes vulnerable, unlock A , abort T a.withdraw(200); write locks A unlock A B , Deadlock Resolution Using Timeout

19. Increasing Concurrency -- Two-VersionLocking • Two versions of an object – tentative and final (committed). • All writes go to tentative version, all other operations go to committed version of the object (unless this object has been previously read before by this transaction itself). • Three types of locks on an object – read, write and commit Rules: • To perform a read operation, a read lock must be set on the object – always successful unless the object already has a commit lock. • To perform a write operation, a write lock must be set on the object – always successful unless the object already has a write or commit lock. • To commit a transaction, the coordinator attempts to convert all its write locks to commit locks. If this succeeds, it sets the committed version to the value of the tentative version (for each object). • Transactions cannot commit writes, if other trans. that read the object are not complete yet.

20. For one object Lock to be set read write commit Lock already set none OK OK OK read OK OK wait write OK wait commit wait wait Lock Compatibility (read, write and commitlocks)

21. Increasing Concurrency -- Two-VersionLocking • Compared to read-write locking, read lock requests wait only for commits (and not for writes). • Compared to read-write locking, this increases concurrency but may cause more commit attempts to fail • Transactions cannot commit writes, if other trans. that read the object are not complete. • Can deadlocks happen due to read-commit waits?

22. Conclusion? • Applications care about concurrency because it improves performance • Applications are willing to tolerate temporary inconsistency and deadlocks in turn • These inconsistencies and deadlocks need to be prevented or detected • Driven and validated by actual application characteristics – mostly-read applications do not have too many conflicting operations anyway • Reading for next lecture: Sections 13.5-13.7 • HW4 due next Tuesday.