1. CONCURRENCY CONTROL SECTION 18.7 THE TREE PROTOCOL By : Saloni Tamotia (215)

2. BASICS  B-Trees - Tree data structure that keeps data sorted - allow searches, insertion, and deletion - commonly used in database and file systems  Lock - Enforce limits on access to resources - way of enforcing concurrency control  Lock Granularity - Level and type of information that lock protects.

3. TREE PROTOCOL  Kind of graph-based protocol  Alternate to Two-Phased Locking (2PL)  database elements are disjoint pieces of data  Nodes of the tree DO NOT form a hierarchy based on containment  Way to get to the node is through its parent  Example: B-Tree

4. ADVANTAGES OF TREE PROTOCOL  Unlocking takes less time as compared to 2PL  Freedom from deadlocks

5. 18.7.1 MOTIVATION FOR TREE-BASED LOCKING  Consider B-Tree Index, treating individual nodes as lockable database elements.  Concurrent use of B-Tree is not possible with standard set of locks and 2PL.  Therefore, a protocol is needed which can assure serializability by allowing access to the elements all the way at the bottom of the tree even if the 2PL is violated.

6. 18.7.1 MOTIVATION FOR TREE-BASED LOCKING (cont.) Reason for : “Concurrent use of B-Tree is not possible with standard set of locks and 2PL.”  every transaction must begin with locking the root node  2PL transactions can not unlock the root until all the required locks are acquired.

7. 18.7.2 ACCESSING TREE STRUCTURED DATA Assumptions:  Only one kind of lock  Consistent transactions  Legal schedules  No 2PL requirement on transaction

8. 18.7.2 RULES FOR ACCESSING TREE STRUCTURED DATA RULES:  First lock can be at any node.  Subsequent locks may be acquired only after parent node has a lock.  Nodes may be unlocked any time.  No relocking of the nodes even if the node’s parent is still locked

9. 18.7.3 WHY TREE PROTOCOL WORKS?  Tree protocol implies a serial order on transactions in the schedule.  Order of precedence: Ti < s Tj  If Ti locks the root before Tj, then Ti locks every node in common with Tj before Tj.

10. ORDER OF PRECEDENCE

11. CONCURRENCY CONTROL SECTION 18.8 Timestamps By : Rupinder Singh (216)

12. What is Timestamping? Scheduler assign each transaction T a unique number, it’s timestamp TS(T). Timestamps must be issued in ascending order, at the time when a transaction first notifies the scheduler that it is beginning.

13. Timestamp TS(T) Two methods of generating Timestamps. – Use the value of system, clock as the timestamp. – Use a logical counter that is incremented after a new timestamp has been assigned. Scheduler maintains a table of currently active transactions and their timestamps irrespective of the method used

14. Timestamps for database element X and commit bit RT(X):- The read time of X, which is the highest timestamp of transaction that has read X. WT(X):- The write time of X, which is the highest timestamp of transaction that has write X. C(X):- The commit bit for X, which is true if and only if the most recent transaction to write X has already committed.

15. Physically Unrealizable Behavior Read too late: A transaction U that started after transaction T, but wrote a value for X before T reads X. U writes X T reads X T startU start

16. Physically Unrealizable Behavior Write too late A transaction U that started after T, but read X before T got a chance to write X. U reads X T writes X T startU start Figure: Transaction T tries to write too late

17. Dirty Read It is possible that after T reads the value of X written by U, transaction U will abort. U writes X T reads X U startT startU aborts T could perform a dirty read if it reads X when shown

18. Rules for Timestamps-Based scheduling 1. Scheduler receives a request rT(X) a) If TS(T) ≥ WT(X), the read is physically realizable. 1. If C(X) is true, grant the request, if TS(T) > RT(X), set RT(X) := TS(T); otherwise do not change RT(X). 2. If C(X) is false, delay T until C(X) becomes true or transaction that wrote X aborts. b) If TS(T) < WT(X), the read is physically unrealizable. Rollback T.

19. Rules for Timestamps-Based scheduling (Cont.) 2. Scheduler receives a request WT(X). a) if TS(T) ≥ RT(X) and TS(T) ≥ WT(X), write is physically realizable and must be performed. 1. Write the new value for X, 2. Set WT(X) := TS(T), and 3. Set C(X) := false. b) if TS(T) ≥ RT(X) but TS(T) < WT(X), then the write is physically realizable, but there is already a later values in X. a. If C(X) is true, then the previous writers of X is committed, and ignore the write by T. b. If C(X) is false, we must delay T. c) if TS(T) < RT(X), then the write is physically unrealizable, and T must be rolled back.

20. Rules for Timestamps-Based scheduling (Cont.) 3. Scheduler receives a request to commit T. It must find all the database elements X written by T and set C(X) := true. If any transactions are waiting for X to be committed, these transactions are allowed to proceed. 4. Scheduler receives a request to abort T or decides to rollback T, then any transaction that was waiting on an element X that T wrote must repeat its attempt to read or write.

21. Multiversion Timestamps Multiversion schemes keep old versions of data item to increase concurrency. Each successful write results in the creation of a new version of the data item written. Use timestamps to label versions. When a read(X) operation is issued, select an appropriate version of X based on the timestamp of the transaction, and return the value of the selected version.

22. Timestamps and Locking Generally, timestamping performs better than locking in situations where: – Most transactions are read-only. – It is rare that concurrent transaction will try to read and write the same element. In high-conflict situation, locking performs better than timestamps

23. Questions ???