Scribd
Upload
265 views2 pages

(B) (I) Discuss On Two-Phase Locking Protocol and Timestamp-Based Protocol

Two common protocols for ensuring serializability in database transactions are two-phase locking and timestamp ordering. Two-phase locking requires that locks are acquired in a growing phase and released in a shrinking phase to prevent deadlocks. Timestamp ordering compares the timestamps of transactions to the read and write timestamps of data items to prevent transactions from violating the timestamp order. Both approaches aim to ensure transactions appear to execute serially, but two-phase locking does not prevent deadlocks while timestamp ordering aborts transactions if the timestamp order is violated.

Uploaded by

compiler&automata
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
265 views2 pages

(B) (I) Discuss On Two-Phase Locking Protocol and Timestamp-Based Protocol

Two common protocols for ensuring serializability in database transactions are two-phase locking and timestamp ordering. Two-phase locking requires that locks are acquired in a growing phase and released in a shrinking phase to prevent deadlocks. Timestamp ordering compares the timestamps of transactions to the read and write timestamps of data items to prevent transactions from violating the timestamp order. Both approaches aim to ensure transactions appear to execute serially, but two-phase locking does not prevent deadlocks while timestamp ordering aborts transactions if the timestamp order is violated.

Uploaded by

compiler&automata
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

11/3/2018 (b) (i) Discuss on two-phase locking protocol and timestamp-based protocol

One protocols that ensures serializability is the two-phase locking protocol. This protocol requires that each
transaction issue lock and unlock requests in two phases:
1. Growing phase. A transaction may obtain locks, but may not
release any lock.
2. Shrinking phase. A transaction may release locks, but may
not obtain any new locks.

Initially, a transaction is in the growing phase. The transaction acquires locks as needed. Once the transaction
releases a lock, it enters the shrinking phase, and it can issue no more lock requests.

Suppose two-phase locking does not ensure serializability. Then there exists a set of transactions T0, T1, ... Tn-1
which obey 2PL and which produce a non-serializable schedule. A

non-serializable schedule implies a cycle in the precedence graph, and we shall show that 2PL cannot produce
such cycles. Without loss of generality, assume the following cycle exists in the precedence graph: T0 -> T1->
T2 -> ... -> Tn-1-> T0 -> Let α1 be the time at which Ti obtains its last lock (i.e. Ti's lock point). Then for all
transactions such that Ti -> Tj, αi < αj
Then for the cycle we have:
α1 < α2 < α3 …… αn-1
no such cycle can exist. Hence 2PL cannot produce nonserializable schedules. Because of the property that for
all transactions such that Ti -> Tj, αi < αj the lock point ordering of the transactions is also a topological sort
ordering of the precedence graph. Thus transactions can be serialized according to their lock points.

Two phase locking does not ensure freedom from deadlock.


Lock and unlock instructions:
Lock-S (A)
read (A)
lock-X (B)
read (B)
If A = 0
Then B: = B + 1
Write (B)
Unlock (A)
Unlock (B)

T32: lock-S (B)


Read (B)
Lock-X (A)
Read (A)
If B = 0
Then A: = A + 1
Write (A)
Unlock (B)
Unlock (A)
b. Execution of these transactions can result in deadlock. For example, consider the following partial schedule:

T31 T32
Lock-S (A)
http://enggedu.com/source_code/java/RMI_Program.php/tamilnadu/university_questions/question_answer/be_nd_2006/5th_sem/cse/cs1301/part_b/1… 1/2
11/3/2018 (b) (i) Discuss on two-phase locking protocol and timestamp-based protocol

Lock-S (B)
Read (B)
Read (A)
Lock-X (B)
Lock-X (A)

The transactions are now deadlocked.

Cascading rollbacks can be avoided by a modification of two phase locking called the strict two phase
locking protocol. This protocol requires not only that locking be two phase, but also that all exclusive-mode
locks taken by a transaction be held until that transaction commits. This requirement ensures that any data
written by an uncommitted transaction are locked in exclusive mode until the transaction commits, preventing
any other transaction from reading the data.
This observation leads us to a refinement of the basic two phase locking protocol, in which lock
conversions are allowed.
We shall provide mechanism for upgrading a shared lock to an exclusive lock, and downgrading an exclusive
lock to a shared lock. We denote conversion from shared to exclusive modes by upgrade, and from exclusive to
share by downgrade. Lock conversion cannot be allowed arbitrarily. Rather, upgrading can take place in only the
growing phase, whereas downgrading can take place in only the shrinking phase.

Returning to our example, transactions T8 and T9 can run concurrently under the refined two phase locking
protocol, as shown in the incomplete schedule of fig., where only some of the locking instructions are shown.

T8 T9
Lock-S (a1)
Lock-S (a1)
Lock-S (a2)
Lock-S (a2)
Lock-S (a3)
Lock-S (a4)
Unlock-S (a1)
Unlock-S (a2)
Lock-S (an)
Upgrade (a1)

Basic Timestamp Protocol

Whenever some transaction T tries to issue a read-item(x) or a write-item(x) operation, the basic timestamp
ordering algorithm compares the timestamp of T with read_TS(x) and write_TS(x) to ensure that the timestamp
order of transaction execution is not violted. If this order is violated, then transaction T is aborted and
resubmitted to the system as a new transaction with a new timestamp.
1. Transaction T issues a write-item(x) operation:
(a) If read_TS(x) > TS(T) or if we write_TS(x) > TS(T), then abort and roll back T and reject the operation.
This should be done because some younger transaction with a timestamp greater than TS(T) has already read or
written the value of item X before T had a chance to write X, thus violating the timestamp ordering.
(b) If the condition in (a) does not occur, then execute the write_TS(x) to TS_(T).

2. Transaction T issues a read_item(X) operation

(a)If write_TS(x) > TS(T), then abort and roll back T and reject the operation. This should be done because
some younger transaction with timestamp greater than TS(T) has already written the value of item X before T
had a chance to read X.
(b)If write_TS(x) <= TS(T), then execute that read_item(X) operation of T set read_TS(x) to the larger of TS_T
and the current read_TS(x).

http://enggedu.com/source_code/java/RMI_Program.php/tamilnadu/university_questions/question_answer/be_nd_2006/5th_sem/cse/cs1301/part_b/1… 2/2

You might also like