Concurrency Control Managing Hierarchies of Database Elements (18.6) 1 Presented by Ronak Shah (214) March 9, 2009

Managing Hierarchies of Database Elements Two problems that arise with locks when there is a tree structure to the data are: When the tree structure is a hierarchy of lockable elements – Determine how locks are granted for both large elements (relations) and smaller elements (blocks containing tuples or individual tuples) When the data itself is organized as a tree (B-tree indexes) – This will be discussed in the next section

Locks with Multiple Granularity A database element can be a relation, block or a tuple Different systems use different database elements to determine the size of the lock Thus some may require small database elements such as tuples or blocks and others may require large elements such as relations

Warning (Intention) Locks These are required to manage locks at different granularities – In the bank example, if the a shared lock is obtained for the relation while there are exclusive locks on individual tuples, unserializable behavior occurs The rules for managing locks on hierarchy of database elements constitute the warning protocol

Database Elements Organized in Hierarchy

Rules of Warning Protocol These involve both ordinary (S and X) and warning (IS and IX) locks The rules are: – Begin at the root of hierarchy – Request the S/X lock if we are at the desired element – If the desired element id further down the hierarchy, place a warning lock (IS if S and IX if X) – When the warning lock is granted, we proceed to the child node and repeat the above steps until desired node is reached

Compatibility Matrix for Shared, Exclusive and Intention Locks ISIXSX ISYes No IXYes No SYesNoYesNo X The above matrix applies only to locks held by other transactions

Group Modes of Intention Locks An element can request S and IX locks at the same time if they are in the same transaction (to read entire element and then modify sub elements) This can be considered as another lock mode, SIX, having restrictions of both the locks i.e. No for all except IS SIX serves as the group mode

Example Consider a transaction T 1 as follows – Select * from table where attribute1 = ‘abc’ – Here, IS lock is first acquired on the entire relation; then moving to individual tuples (attribute = ‘abc’), S lock in acquired on each of them Consider another transaction T 2 – Update table set attribute2 = ‘def’ where attribute1 = ‘ghi’ – Here, it requires an IX lock on relation and since T 1 ’s IS lock is compatible, IX is granted

– On reaching the desired tuple (ghi), as there is no lock, it gets X too – If T2 was updating the same tuple as T1, it would have to wait until T1 released its S lock

Phantoms and Handling Insertions Correctly This arises when transactions create new sub elements of lockable elements Since we can lock only existing elements the new elements fail to be locked The problem created in this situation is explained in the following example