

Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Prof. Ganapati Sadayappan distributed this handout in class of Database Fundamentals course at Aligarh Muslim University. Its main points are: Transactions, Activity, Isolation, Levels, Serializable, Repeatable, Read, Locking, Committed
Typology: Study notes
1 / 2
This page cannot be seen from the preview
Don't miss anything!


Consider a table Football(college, league, rank). Write two transactions, X 1 and X 2 , consisting of SQL queries and/or updates over Football. Assume that transaction X 1 always executes with isolation level Serializable , and that both transactions always run to completion. Your transactions should be designed so that their possible behaviors are different for the four possible isolation levels for transaction X 2 :
Serializable Repeatable Read Read Committed Read Uncommited
In addition to specifying your two transactions, give an initial state of table Football so that the values retrieved in Select statements by one or both of the transactions, and/or the final state of table Football , may be different for each of the four isolation levels for transaction X 2.
Consider a locking protocol intended to enforce the various isolation levels offered to transactions. Assume each transaction T acquires the necessary locks just before each operation it performs, retains acquired locks for the duration of transaction T , then releases all of its locks when T either commits or rolls back. There are three types of locks:
A READ lock on a tuple t ― records that a transaction is reading tuple t A WRITE lock on a tuple t ― records that a transaction is updating or deleting tuple t An INSERT lock on a table T ― records that a transaction is inserting into table T
Here's the proposed protocol. In each group after the first one, the italicized line indicates what’s changed from the previous group.
SERIALIZABLE transactions
REPEATABLE READ transactions 1) No global checking for INSERT locks
READ COMMITTED transactions
READ UNCOMMITTED transactions
Unfortunately this implementation protocol does not work. Find as many bugs in the protocol as you can. A bug is demonstrated by showing two transactions X 1 and X 2 that follow the protocols for their isolation levels, but some possible behavior when the transactions are executed concurrently does not conform to the requirements of the isolation levels. Some notes:
We don’t consider the possibility of deadlock to be a bug. We’re not concerned about the protocols being too conservative ― i.e., imposing more restrictions than necessary ― but rather when the protocols don’t enforce the required consistency. Your examples may include transactions that commit and/or rollback, but try to find at least one bug that does not involve rollback. Your examples may include insertions, deletions, and/or updates, but try to find at least one bug that does not involve insertions. (Disclaimer: We haven’t found one yet ourselves, but we don’t know that there isn’t one either!)