|
|
Strict Two-phase LockingIn computer science, strict two-phase locking (Strict 2PL) is a locking method used in database management systems. The two rules of Strict 2PL are: - If a transaction T wants to read/write an object, it must request a shared/exclusive lock on the object.
- All locks held by transaction T are released when T commits (and not before).
Here is an example of Strict 2PL in action with interleaved actions. -
T1 & T2 \\ S(A) & \\ R(A) & \\ & S(A) \\ & R(A) \\ & X(B)\\ & R(B) \\ & W(B)\\ & Com. \\ X(C) & \\ R(C) & \\ W(C) & \\ Com. &\end{bmatrix} or in text form: T1: S(A), R(A); T2: S(A), R(A), X(B), R(B), W(B), Commit; T1: X(C), R(C), W(C), Commit where - S() is a shared lock action on an object
- X() is an exclusive lock action on an object
- R() is a read action on an object
- W() is a write action on an object
Strict 2PL prevents transactions reading uncommitted data, overwriting uncommitted data, and unrepeatable reads. It does not guarantee that deadlocks cannot occur, which can be important in real time systems, and may additionally be difficult to enforce in distributed data bases, or fault tolerant systems with multiple redundancy. A deadlocked schedule supposedly allowed in Strict 2PL: -
T1 & T2\\ X(A) & \\ & X(B) & \\ X(B) & \\ & X(A) \end{bmatrix} Text: T1: X(A) T2:X(B) T1:X(B) T2: X(A) T1 is waiting for T2's lock on B to be released, while T2 is waiting for T1's lock on A to be released. These transactions cannot proceed and both are deadlocked. If a user wishes to guarantee that no deadlocks occur, non-strict 2PL would be one option. Assigning timestamps would be another.
|
 |