1. Section 18.6: Managing Hierarchies of Database Elements
Amie Radenbaugh
CS257: Database Systems
San José State University

2. Agenda Hierarchies Warning Locks and Warning Protocol
Database Elements
Hierarchy of Lockable Elements
Example Applications
Warning Locks and Warning Protocol
Types of Warning Locks
Rules of Warning Protocol
Compatibility Matrix
Handling Insertions & Phantom Elements

3. What are Database Elements?
The term “Database Element” can refer to a variety of elements in the database
Different systems lock different sizes of database elements (e.g. Relations, Blocks, Tuples)
Depends on the Application and the structure of the data that the Database is used for

4. Database Elements Organized in a Hierarchy

5. Hierarchies Hierarchy of lockable elements Data organized in a tree
Locks on large elements (e.g. Relations)
Locks on smaller elements (e.g. Blocks or Tuples)
Data organized in a tree
B-tree indexes (covered in another section)

6. Example of Bank Application
Relation: Account Balances
Block: Accounts
Tuples: Add/Deposit, Remove/Withdraw, Sum

7. Example of Bank Application
If Locks occurred on the Relation Level, then there would only be one lock for an entire Account Balances Relation.
Most transactions will change the overall Account Balances, therefore most transactions would need an exclusive lock on the Account Balances Relation
Only one deposit or withdrawal could take place at any time
Result: The system would allow very little concurrency!

8. Example of Bank Application
Only lock individual Account Blocks or Account Tuples
Providing a Lock for every Tuple is too fine-grained and is probably not worth the effort

9. Example: Database of Documents
Documents may be edited from time to time
Most transactions will read entire documents
Locks should happen on the document level
Locking is only necessary to avoid reading a document that is in the middle of being edited
Locking every paragraph or sentence is too fine-grained with essentially no benefit

10. Large- and Small-Grained Locks in Parallel
Bank Application
Needs locking at Account Block or Tuple level
Might also need locking at Account Balances Relation level (e.g. Auditing)

11. Warning Locks & Warning Protocol
Solution to the problem of managing locks at different granularities
Warning Protocol
Rules for managing locks on a hierarchy of database elements
Combines ordinary locks (e.g. Shared, Exclusive) with warning locks

12. Warning Locks Notation
S: Shared lock
X: Exclusive lock
IS: Intention to obtain a Shared lock
IX: Intention to obtain an Exclusive lock

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

14. Compatibility Matrix

15. Compatibility Matrix Consider the IS Column:
Requesting an IS Lock at Node N means we intend to read a sub-element of N
This is only a problem if some other Transaction already has an X lock on the Node

16. Compatibility Matrix Note on IS column
If there is an IX lock at N, then we can grant the IS lock at N, and allow the possible conflict to be found at a lower level if indeed the intent to write and the intent to read involve the same sub-element

17. Compatibility Matrix Consider the IX Column:
Requesting an IX Lock at Node N means we intend to write to a sub-element of N
This is a problem if some other Transaction already has an S or X lock on Node N

18. Compatibility Matrix Note on IX column
Similar to the IS Column, granting an IX at Node N may or may not conflict with another IX or IS that has been previously granted at N, but the conflict will be dealt with at a lower level if indeed the intent to read or write involves the same sub-element

19. Compatibility Matrix Consider the S Column:
Reading Node N does not conflict with another read lock on N nor a read lock on some sub-element of N (IS at N)
Either an X or an IX means that some other transaction will write at least part of N, thus we cannot read all of N

20. Compatibility Matrix Consider the X Column:
We cannot allow writing of all of node N if any other transaction already has the right to read or write N, or has the intent to read or write on a sub-element of N

21. Example of Warning Protocol
Consider Relation:
Token(term, tfidf, frequency)
SELECT * FROM Token WHERE term = ‘*tion’;

22. Example of Warning Protocol
Transaction1:
SELECT * FROM Token WHERE term = ‘*tion’;
IS Lock on Document
S Lock on existing Tokens where term ends with “tion”
Transaction2:
UPDATE Token SET tfidf = 1.5 WHERE term = ‘the’;
Need an IX Lock on Document
Transaction1’s IS lock is compatible so the lock is granted
Need an X lock on the Token where the term = “the”
There is no lock on the Token, so the lock is granted

23. Example of Warning Protocol
Transaction1:
SELECT * FROM Token WHERE term = ‘*tion’;
IS Lock on Document
S Lock on existing Tokens where term ends with “tion”
Transaction2:
UPDATE Token SET tfidf = 1.5 WHERE term = ‘execution’;
Need an IX Lock on Document
Transaction1’s IS lock is compatible so the lock is granted
Need an X lock on the Token where the term = “execution”
Transaction1 has an S lock on this Token, so Transaction2 has to wait until Transaction1 releases the lock

24. Insertions
Transactions that create new sub-elements can cause problems
We can only lock existing items
Examples:
Insertion: If 2 Transactions try to insert the same new element we run into a concurrency problem
Phantom Elements

25. Phantom Example Consider Relation: Token(term, tfidf, frequency)
SELECT * FROM Token WHERE frequency > 10;

26. Phantom Example Transaction1: Transaction2:
SELECT * FROM Token WHERE frequency > 10;
IS Lock on Document
S Lock on existing Tokens where frequency > 10
Read Token1
Read Token2
Transaction2:
Inserts a new Token3 with frequency 11 to the Document

27. Phantom Example
Transaction 1 will return an incorrect answer. The cursor will not include Token3.
This is a phantom element. Token3 should have been locked by Transaction1 but it didn’t exist at the time the locks were taken.
We must regard the insertion or deletion of a tuple as a write operation on the relation as a whole