THREE-PHASE LOCKING (3PL)

by jasim qazi [121]

Problems with 2PL 2PL has performance issues when

dealing with frequently-changing data in multi user environments: Deadlocks: multiple users so concurrency

a major issue. Added to the number of data access, deadlocks occur.

Problems with 2PL(UPDATE) Cascading Rollbacks: in

this case if an error occurs after the Read(A,a) operation of T1, then T1 will have to rollbackand start over. Since T2 and T3 are waiting for the result of T1, these two will also be rolled back till T1 executes correctly.

T1 T2 T3Lock(A)Read(A,a)Lock(B)Read(B,b)Write(A,a)Unlock(A)

Lock(A)Read(A,a) Write(A,a)Unlock(A)

Lock(A)Read(A,a)

3PL Not a necessity, not used a lot. Procedures available to solve 2PL’s

problems. Dependent on the nature of the data and the

environment: changing data, many users. Types of locks used: Read, Write, Write

Intent.

Scenario User signs in and requests data from

the database. Read lock is applied to the data. Once the data is read, the Read lock is

dropped. There can be multiple Read locks by

multiple users on the same data/tuple.

Scenario When the user indicates that he wishes to edit the

data, take out a WRITE-INTENT lock. UPDATE:Write Intent Lock also known as Change

Lock or Protect Lock. Other users can still obtain a Read Lock on the

data. Write Lock allowed only to the user who has the

Write Intent Lock. If data locked with Write Intent Lock, then no

further Write Intent Locks can be applied on it.

Scenario When user finishes editing the data and

submits the changes, immediately Write Lock is applied on the data.

Write Intent Lock is unlocked. Transaction is committed and Write Lock

is unlocked.

3PL All locks are subject to timeouts, with appropriate

actions (unlocks, error/warning messages to user etc) taken in the event of lock failure. This prevents deadlocks.

All access to the data in question should use the same locking protocol. No other protocol should be applied or considered as it may disrupt the flow of operations.

UPDATE:Only WRITE-INTENT locks can be held for any length of time, typically because the record of interest is at the mercy of the user in edit mode...

Final words… This is actually not dissimilar to the way

many "modern" relational databases handle locking,

The average RDBMS can't support the degree of control involved here

3PL developed out of need.