Database Isolation

Isolation is the database-level property that controls how and when changes are made and if they become visible to each other. One of the goals of isolation is to allow multiple transactions occurring at the same time without impacting each other’s execution.

Capture.PNG

Lost update: a transaction write is ignored by another transaction. write->write
Dirty read: a transaction reads an object written by another transaction which again modifies the object afterwards. write->read
Non repeatable read: a transaction reads an object twice and gets different values. read->write

Mode of Lock

Capture.PNG

Dependency relation

In a history sequence H, consisting of tuples of the form
(T, action, object).
If T1 and T2 are transactions, O is an object, and there exists
indexes i and j such that i < j, H[i] involves action a1 on O by
T1, (i.e. H[i] = (T1,a1,O)) H[j] involves action a2 on O by
T2 (i.e. H(j) = (T2, a2,O)) and there are no
H(k) = (T’,WRITE,O) for i < k < j, the
dependency of T1 on T2 can be written as:
(T1, O, T2)
A history is said to be isolated if it is equal to a serial history.
A serial history is history that is resulted as a consequence of
running transactions sequentially one at a time. N transactions
can result in a maximum of N! serial histories.

Capture1.PNG

Wormhole theorem: A history is isolated if and only if it has no
wormholes.

Isolation Concept:

A transactions is a sequence of READ, WRITE, SLOCK, XLOCK actions on objects ending with COMMIT or ROLLBACK.
A transaction is well formed if each READ, WRITE and UNLOCK operation is covered earlier by a corresponding lock operation.
A history is legal if does not grant conflicting grants.
A transaction is two phase if its all lock operations precede its unlock operations
Locking theorem: If all transactions are well formed (READ, WRITE and UNLOCK operation is covered earlier by a corresponding lock operation) and two-phased, then any legal (does not grant conflicting grants) history will be isolated.
Locking theorem (Converse): If a transaction is not well formed or is not two-phase, then it is possible to write another transaction such that it is a wormhole.
Rollback theorem: An update transaction that does an UNLOCK and then does a ROLLBACK is not two phase.

Degree of Isolation

image.png

Granularity of Locking

Problem:
C1 queries DB for all suspects with blue eyes red hair and C2 inserts new suspect with blue eyes & red hair, C1 may lock all appropriate suspects, but this won't prevent C2 from inserting new suspect, violating consistency
Phantoms and predicate locks

phantom lock

sometimes called an anti-insert lock, is placed on a scan position to prevent the subsequent creation of phantom rows by other transactions. When a phantom lock is acquired, it prevents other transactions from inserting a row into a table immediately before the row that is anti-insert locked. A phantom lock is a long-term lock, that is held until the end of the transaction.

Predicate lock

Predicate locking is a method of locking based upon logical conditions as a solution to so-called phantom rows, such that if a transaction has issued SELECT ... WHERE age > 18, no other transaction would be able to add new rows where age greater than 18, delete rows where age greater than 18, or update an existing row so that it would conflict with the initial transaction.

It is NP complete
Hard to capture predicates

Solution

Granular Lock:

Build hierarchy and locks can be taken at any level will automatically grant the locks on its descendants

Update lock mode

The situation here could cause deadlock, as after anyone of the T1, T2, T3 acquire share lock, no one could require the exclusive lock.
Solution 1
Solution 2

Capture.PNG

Optimistic Locking

Allows you to lower the isolation level that you use in an application so that fewer locks are placed on the database
It is effective two phase locking with short-duration of locking.
It allows more applications to run concurrently against the database, and potentially increase the throughput of your applications.