1. Dynamic Granular Locking Approach to Phantom Protection in R-trees Kaushik Chakrabarti Sharad Mehrotra Department of Computer Science University of Illinois at Urbana Champaign http://mars.cs.uiuc.edu/db Presented at: ICDE 98

2. MARS February 27, 1998 ICDE 98 Multidimensional Index Structures §Applications: GIS, CAD, Content-based multimedia retrieval, time-series §Data structures: R-trees, k-d-B-trees, hB- trees, X-trees, TV-trees, SS-trees §Most of them not supported in any commercial system (Exception: R-tree in Informix Universal Server as Spatial Datablade)

3. MARS February 27, 1998 ICDE 98 Why Multidimensional Index Structures are NOT supported as ACCESS METHODS by commercial DBMSs today? §Lack of protocols to concurrent access to data via multidimensional index structures §Two problems of concurrency control: l Preserving the physical consistency of the data structure l Phantom protection This paper provides an approach to phantom protection in R-trees.

4. MARS February 27, 1998 ICDE 98 Why do we choose R-trees in preference to other multidimensional access methods? §The most popular multidimensional index structure used today §Only one used in a commercial DBMS (Informix IUS)

5. MARS February 27, 1998 ICDE 98 What are phantoms? §Consider a range query over a B-tree based on employee salary: select employees where 50K < salary < 100K §Locking all employee records do not prevent insertion of an employee making 80K after the read is over but before it commits because there is no lock on nonexistent records. §Insertions may be due to new insertions or rolling back deletions. §If the searcher repeats its scan, it finds a new record appeared from nowhere --- PHANTOM! §Not repeatable read => not serializable.

6. MARS February 27, 1998 ICDE 98 Approaches to Phantom Protection PREDICATE LOCKING §lock predicates instead of objects §lock granted if predicates don’t conflict (or modes don’t conflict) §needs checking for predicate satisfiability to detect conflicts §too expensive to be used in a LM §not used in any commercial DBMS GRANULAR LOCKING §engineering approach to predicate locks §key space divided in resource granules §conflicting predicate locks must request conflicting granular locks on at least one granule in common §locks acquired on granules -- as efficient as object locks §used in all commercial DBMSs

7. MARS February 27, 1998 ICDE 98 How are phantoms prevented in B-trees? §Key ranges (k, k i+1 ], defined by the ordered list of attribute values present in the B-tree such that k < k i+1, serve as granules

8. MARS February 27, 1998 ICDE 98 Can KRL be generalized for R-trees? §No : KRL relies on total order of underlying objects based on their key values. Such an order does not exists for spatial objects indexed using R-trees.

9. MARS February 27, 1998 ICDE 98 Granular Locks

10. MARS February 27, 1998 ICDE 98 Criteria for choosing lock granules §Define resource granules: l dynamic l covering l fine §Easy mapping of predicates to locks §Take care of possibility of overlap among granules - no exclusive lock coverage

11. MARS February 27, 1998 ICDE 98 R-trees §Leaf granules: BR(R3), BR(R4), BR(R5), BR(R6), BR(R7) §External Granules l ext(root) covering S-(BR(R1) U BR(R2)) l ext(R1) covering BR(R1)-(BR(R3) U BR(R4) U BR(R5)) l ext(R2) covering BR(R2)-(BR(R6) U BR(R7))

12. MARS February 27, 1998 ICDE 98 Rtree

13. MARS February 27, 1998 ICDE 98 R-trees

14. MARS February 27, 1998 ICDE 98 Resource Granules in R-trees §Leaf granules (lowest level BRs) §External granules (BR of non-leaf node minus BRs of all its children)

15. MARS February 27, 1998 ICDE 98 Strategies §Searcher acquires S locks on all overlapping granules §Inserter acquires IX lock on the minimal covering set of granules §Suitable for R-trees since searchers follow all overlapping paths §Searcher acquires S locks on the minimal covering set of granules §Inserter acquires IX locks on all overlapping granules §Suitable for R+-trees since inserters follow all overlapping paths

16. MARS February 27, 1998 ICDE 98 They don’t work!

17. MARS February 27, 1998 ICDE 98 Why? §An insertion may cause the loss of coverage of an S lock

18. MARS February 27, 1998 ICDE 98 How to avoid it? §Require inserters to acquire short duration IX locks on all overlapping granules §Overhead: Extra disk access

19. MARS February 27, 1998 ICDE 98 Overhead Optimization §ONLY the insertions that causes the granule boundary to change acquires short duration IX locks on all overlapping granules in addition to the commit duration IX on the target granule. Others acquire only the target granule lock. §Reduces overhead drastically: Only 4% of the insertions change granule boundaries for a R-tree with fanout 50.

20. MARS February 27, 1998 ICDE 98 Can a searcher’s lock even on an external granule lose it coverage? §Yes. Here’s an example:

21. MARS February 27, 1998 ICDE 98 How to avoid it? §When the granule grows, inserter acquires a short duration SIX on the external granule of the parent.

22. MARS February 27, 1998 ICDE 98 Node Splits §Can cause loss of lock coverage §Prevented by requesting a short duration SIX on the leaf/external granule being split

23. MARS February 27, 1998 ICDE 98 Deletions §Deletion can cause loss of lock coverage of the deleter §Prevented by logical deletion §Physical deletion on/after commit (synchronous/asynchronous) §IX lock on the granule before deletion

24. MARS February 27, 1998 ICDE 98 Lock Protocols §Search: commit duration S locks on all overlapping granules §Insertion: l No granule change: commit duration IX on the target granule l Granule change: commit duration IX on target granule and short duration IX on all overlapping granules/external granules l Node split: short duration SIX on target granule before split; IX lock on granules formed after split §Deletion: l Logical deletion l Asynchronous physical deletion (garbage collection)

25. MARS February 27, 1998 ICDE 98 Comparison to Predicate Locking Granular Locking §High concurrency by choosing fine granules (lower than PL) §Low lock overhead (no predicate checking ) §Small I/O overhead for some insertions §Lock overhead independent of MPL §Can be implemented using a regular LM Predicate Locking §Maximum permissible concurrency §High lock overhead ( involves predicate checking) §Space overhead of maintaining predicates §Lock overhead increases with MPL §Needs a separate predicate manager component

26. MARS February 27, 1998 ICDE 98 Conclusions §Concurrency control protocols are crucial to integration of multidimensional index structures as access methods to DBMSs. This paper is a step towards that. §Granular locking provides slightly lower concurrency compared to PL but is more efficient than PL. Proper comparison is possible after implementation of both protocols and measuring throughput and response time Slides available at: http://mars.cs.uiuc.edu/db