Managing Hierarchies of Database Elements Section 18.6 CS257 Jack Price

Key Points Locks with Multiple Granularity (MGL) Warning Locks Phantoms and Handling Insertions Correctly

Introduction 2 problems when there is a tree structure in Concurrency-controlled systems Hierarchy of lockable elements o Allowing locks on small and large elements Data organized in a tree o Schemes perform poorly when we view nodes of B-tree as DB elements

Multiple Granularity Locks (MGL) Database Elements Hierarchy Large Element: Relations Small Elements: Blocks and Tuples

Example Bank Application Requirements If Locks occurred on the Relation Level, then only one lock for an entire Account Balances Relation. If the relation has account balances, only one lock would be very inflexible and provide little concurrency Only one deposit or withdrawal could take place at any time

Bank Application Only lock individual Account Blocks or Account Tuples Perform transactions on different accounts simultaneously

Warning Locks Required to manage locks at different granularities Warning Protocol o Rules for managing locks on a hierarchy of database elements o Combines ordinary locks (e.g. Shared (S), Exclusive (X)) with warning locks

Warning Protocol Rules 1.To place an ordinary S or X lock on any element, we must begin at the root of the hierarchy 2.If we are at the element that we want to lock, request an S or X on that element 3.If the element we wish to lock is further down the hierarchy, then place a warning at this node (IS or IX) 4.Repeat steps 2 or 3 until the desired node is reached

Compatibility Matrix S: Shared lock X: Exclusive lock IS: Intention to obtain a Shared lock IX: Intention to obtain an Exclusive lock

Examples Transaction1: o SELECT * FROM Movie WHERE title = ‘King Kong’; o IS Lock on Entire relation o S Lock on existing Movies where title is “King Kong” Transaction2: o UPDATE Movie SET year = ‘1939’ WHERE title = ‘Gone With the Wind’; o Need an IX Lock on the relation o Transaction1’s IS lock is compatible so the lock is granted o Need an X lock and rewrites the tuple o See figure of locks

Example

Phantoms and Handling Insertions Correctly Token(Term, TFIDF, Frequency) SELECT * FROM Token WHERE frequency > 10

Phantoms and Handling Insertions Correctly Possible problems arise when transactions create new sub elements of lockable elements Can lock only existing elements, new elements fail to be locked Example: Transaction 3 Select Sum(length) from Movie where Studioname = ‘Disney’ o T3 acquires IS for Movie and S for Disney movies Now, a new transaction (T4) is introduced…

Phantoms and Handling Insertions (cont…) Transaction T4 inserts a new tuple having studioname= ‘Disney’, the result of T3 becomes incorrect This is not a concurrency problem since the serial order (T3, T4) is maintained Consider below now: T4 writing new tuple while T3 is reading tuples on same relation o r3(d1);r3(d2);w4(d3);w4(X);w3(L);w3(X) o Want to find total length of all movies under studioName – outcome should be consistent. o Above scenario is not consistent. T3 will not get correct sum because lock on new element (d3) was not obtained.

Cont… The relation has a phantom tuple (the new inserted tuple), which should have been locked but it did not existed when lock was acquired by T3. The occurrence of phantoms can be avoided if all insertion and deletion transactions are treated as write operations (Exclusive lock – X ) on the whole relation.

Thank You