Extra slide #3

Multiple Granularity There are circumstances where it would be advantageous to group several data items, and to treat them as one individual synchronization unit. If Ti needs to access the entire database, and a locking protocol is used, them Ti must lock each item in the database. → time-consuming → a single lock request to lock the entire database If Tj needs to access only a few data items, then it should not be required to lock the entire database (concurrency is lost). multiple levels of granularities(tree) by allowing data items to be of various sizes and defining a hierarchy of data granularities (tree)

Multiple Granularity Suppose that Tj wishes to lock rb6 of Fb. Tj has locked Fb explicitly. rb6 is locked implicitly. How does the system determine whether Tj can lock rb6? → Tj must traverse the tree from the root to rb6. If any node in that path is locked in an incompatable mode, then Tj must be delayed. Suppose that Tk wishes to lock the entire database. Tk should not succeed in locking the root node, since Ti is currently holding a lock on part of the tree (on F6) How does the system determine if the root node can be locked? to search the entire database (x) intention lock modes If a node is locked in an intention mode, explicit locking is being done at a lower level of the tree.

Example Suppose that T18 reads ra2 in Fa. T18 – lock the db, A1, Fa in IS mode and lock ra2 in S mode Suppose that T19 modifies ra9 in Fa. T19 – lock the db, A1, Fa in IX mode and lock ra9 in X mode Suppose that T20 reads all the records in Fa. T20 – lock the db, A1 in IS mode, and lock Fa in S mode Suppose that T21 reads the entire database. T21 – lock the db in S mode * T18, T20, T21 can access the db concurrently. * T19 can execute concurrently with T18, but not with either T20 or T21 Multiple-granularity locking protocol Enhance concurrency and reduce lock overhead Useful in app that include a mix of Short trans that access only a few data items. Long trans that produce reports from an entire file or set of files. Variants : data granularity – dag (directed acyclic graph) Deadlock is possible

TWR T16 T17 Read(Q) Write(Q) Write(Q) Ts(T16) < Ts(T17) -To protocol Ts(T16) < W- Ts(Q) ( ≡ Ts(T17) ) write(Q) : rejected  T16 : rolled back · unnecessary!! -Since T17 has already written Q, the value that T16 is attempting to write is one that will never need to read. a) Ti with Ts(Ti) < Ts(T17) that attempts a Read(Q) will be rolled back, since Ts(Ti) < w- Ts(Q). b) Tj with Ts(Tj) > Ts (T17) must read the value of Q written by T17 (not by T16)

TWR obsolete write ops can be ignored under certain circumstances (Thomas’ write rule) · rules for read ops : unchanged · rules for write ops - In these cases where Ts(Ti) ≥ R – Ts(Q), We ignore the obsolete write ·View serializability 예) ·View equivalent to < T16, T17 >

Multiversion Schemes CC schemes that ensure serializability → by delaying an op or aborting the trans that issued the op Ex) read op Delayed because the appropriate value has not been written yet Rejected because the value that it was supposed to read has already been overwritten These difficulties could be avoided if old copies of each data item were kept (multiversion) To determine easily and quickly which version of the data item should be read. When a read(Q) is issued, the system selects one of the version to be read. → ensure serializability

Multiversion Timestamp Ordering Versions that one no longer needed are removed : Qk and Qj have a W-TS < the TS of the oldest trans in the system → Qk & Qj can be delete. desirable property : a read request never fails and is never made to wait reading is a more frequent op than is writing in typical database systems. undesirable property: reading requires the updating of the R-TS field, resulting in two potential disk accesses rather one. the conflicts between than are resolves through rollbacks rather than through waits -> expensive.

Insert and Delete Operations Until now, our attention → read & write ops Some trans requires not only access to existing data items, but also the ability to create new data items / to delete data items delete(Q) insert(Q) How the presence of delete/insert affects concurrency control Let Ii & Ij be instr of Ti and Tj in S in consecutive order Let Ii = delete(Q) Ij = read(Q). Ii & Ij : conflict (Ii → Ij : logical error, Ij → Ii : read successfully) Ij = write(Q). Ii & Ij : conflict (Ii → Ij : logical error, Ij → Ii : write successfully) Ij = delete(Q). Ii & Ij : conflict (Ii → Ij : logical error, Ij → Ii : logical error) Ij = insert(Q). Ii & Ij : conflict (Ii → Ij : logical error, Ij → Ii : not)

Insert and Delete Operations (Cont’) 2PL an X-lock required before it can be deleted Under TO Protocol If TS(Ti) < R-TS(Q), then the op is rejected and Ti is rolled back If TS(Ti) < W-TS(Q), then the op is rejected and Ti is rolled back Otherwise the delete is executed Insert - similar

Insertion : 2PL – X-lock is required on Q Under TO Phantom Phenomenon If Ti performs an insert(Q), the values R-TS(Q) & W-TS(Q) are set to TS(Ti) Phantom Phenomenon T29 : (access all tuples of the deposit relation) SELECT SUM(balance) FROM deposit WHERE branch-name = ‘Perryridge’; T30 : INSERT INTO deposit VALUES ( ‘Perryridge’, 9732, ‘smith’, 1200 ) Deposit Branch-name Account-number Customer name balance :

Insertion (Cont’) If T29 use the tuple inserted by T30, then T29 read a value written by T30. Thus in S T30 must come before T29. If T29 does not use the tuple inserted by T30, then in S T29 must come before T30. (T29 & T30 는 공통의 tuple을 access 하지 않지만 서로 conflict) CC – tuple granularity 이러한 conflict 탐지가 불가능

Index Locking Protocol We assume that there is an index or account for branch-name. T30 must modify the Perryridge bucket. If T29 reads the Perryridge bucket to locate all tuples pertaining to the Perryridge branch, then T29 and T30 conflict on that bucket. Index-Locking Protocol Every relation must have at least one index. A Ti may lock a ti of a relation in S-mode only if it holds an S-mode lock on an index bucket that contains a pointer to ti. A Ti may lock a ti of a relation in X-mode only if it holds an X-mode lock on an index bucket that contains a pointer to ti. A Ti may not insert a ti into a relation r without updating all indices to r. Ti must obtain locks in X-mode on all index buckets that it modifies. The rules of 2PL must be observed.

Insertion of “Clearview” A lookup that runs concurrently with a split or coalescence may find that the desired search key has been moved to the right-sibling node by split or coalescence ex) Insert “Clearview” Lookup “Downtown” Deletion → deadlock Solution : nodes that contain too few search-key values (violate properties of B+-trees) (Insertions are more frequent than deletions) ⇒ No deadlock

B-link tree protocol Based on locking, but neither 2PL nor tree protocol Every node (rather than just leaves) maintain a pointer to its right sibling <B+-tree proc> Lookup Every node of the B+-tree must be locked in shared mode before it is accessed. Insertion and deletion The shared-mode lock on this node is upgraded to exclusive mode, and insertion or deletion is performed. Split

B-link tree protocol (Cont’d) Coalescence If a node has too few search-key values after a deletion, the node with which it will be coalesced must be locked in exclusive mode. Once these two nodes have been coalesced, an exclusive lock is requested on the parent so that the deleted node can be removed.ⓐⓒ