Strict two-phase locking

The two rules of Strict 2PL are:

1. If a transaction T wants to read/write an object, it must request a shared/exclusive lock on the object.
2. 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.

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:

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 is deadlocked.

If an user wishes to guarantee that no deadlocks occur, 2PL would be one option. Assigning Timestamps would be another.

Referenced By