Chapter- 4

Concurrency Control Techniques

 Objectives of the Chapter

At the end of the chapter 4 : the student able to understand :-

 Locking Techniques for Concurrency Control

 Granularity of Data Items and Multiple Granularity Locking

 Concurrency Control Based on Timestamp Ordering

 Multi-version Concurrency Control Techniques

 Validation (Optimistic) Concurrency Control Techniques

2
 Concurrency Control Techniques
 Concurrency control techniques are those techniques used to ensure the isolation

property of concurrently executing transactions.

Most of the techniques ensure serializability of schedules by using protocols that

guarantees serializability.
Some of the main techniques used to control concurrent execution of transactions are:-

1. Concurrency Control Based on Locking

2. Concurrency Control Based on Timestamp Ordering
3. Multi version Concurrency Control Techniques
4. Optimistic Concurrency Control Techniques
Concurrency Control Based on
Locking

4
 1. Concurrency Control Based on Locking
 A Lock is a variable assigned to any data item in order to keep track of the status of
that data item.
 Also lock is a variable associated with a data item that describes the status of the
item with respect to possible operations that can be applied to it.
 One lock with each data item in the database.
 Locks are used to synchronize(coordinate) the access to the data item.
 A lock guarantees exclusive use of a data item to a current transaction.
 A transaction acquires a lock prior to data access and the lock is released (unlocked)
when the transaction is completed.
 Cont’d.
 Lock and Unlock are atomic operation:-
 Lock(X)- data item X is locked in behalf of the requesting transaction.
 Unlock(X)- data item X is made available to all other transaction.
 Most multiuser DBMSs automatically initiate and enforce locking
procedures.
 All lock information is managed by a lock manager, which is responsible
for assigning, manage and controlling the locks used by the transactions.
 Cont’d.
 A database lock exists to prevent two or more database users from
performing any change on the same data item at the very same time.
 Therefore, it is correct to interpret this technique as a means of
synchronizing access.

Simultaneous access to transactions is not permitted.

 Lock Granularity

 Lock Granularity indicates the level of lock use.

 Locking can take place at the following levels:
1. Database level
2. Table level
3. Page level
4. Row level
5. field (attribute) level
 1. Database Level

 In a database-level lock, the entire database is locked.

 Thus preventing the use of any tables in the database by transaction T2
while transaction Tl is being executed.
 This level of locking is unsuitable for multiuser DBMSs.
 Data access will be very s-l-o-w.
Figure of Database Level
 2. Table Level
 In a table-level lock, the entire table is locked,

 Preventing access to any row by transaction T2 while transaction T1 is using the table. T2 must

wait until T1 unlocks the table.

 If a transaction requires access to several tables, each table may be locked.

 However, two transactions can access the same database as long as they access different tables.

 Table-level locks are less restrictive than database-level locks.

 But it also cause traffic jams when many transactions are waiting to access the same table.

 Table-level locks are not suitable for multiuser DBMSs.

Figure of Table Level
 3. Page Level
 The Page-level always consists of fixed size.
 In a page-level lock, the DBMS will lock an entire disk page.
 A disk page, or page, is the equivalent of a disk block, which can be
described as a directly addressable section of a disk.
 A table can span several pages, and a page can contain several rows of
one or more tables.
 Page-level locks are currently the most frequently used multiuser DBMS
locking method.
Figure of Page Level
 4. Row Level
 A row-level lock is much less restrictive than the locks discussed earlier.
 The DBMS allows concurrent transactions to access different rows of the
same table even when the rows are located on the same page.
 This approach improves the availability of data.
 However, its management requires high overhead because a lock exists for
each row in a table of the database involved in a conflicting transaction.
Figure of Row Level
 5. Field Level

 The field-level lock allows concurrent transactions to access the same

row as long as they require the use of different fields (attributes) within
that row.
 It is the most flexible multiuser data access
 Nevertheless, it is rarely implemented in a DBMS because it requires an
extremely high level of computer overhead and the row-level lock is much
more useful in practice.
 Types of Lock Protocol

Simple Locking 2Phase Locking

Simple 2PL
C 2PL
Strict 2PL
R 2PL

 Regardless of the simple level of locking, the DBMS may use different lock types(mode)
those are:-
1. Binary or
2. Shared/Exclusive
 1. Binary Lock
 A binary lock is a variable capable of holding only 2 possible values.
 Thus two states/values are : locked (1) or unlocked (0).
 Every database operation requires that the affected object be locked.
 If an object is locked by a transaction, no other transaction can use that
object.
 If an object is unlocked, any transaction can lock the object for its use.
 As a rule, a transaction must unlock the object after its termination.
 Cont’d
 Two operations, lock_item and unlock_item, are used with binary locking.
 A transaction requests access to an item X by first issuing a lock_item (X) operation.
 If LOCK(X) =1, the transaction is forced to wait.
 If LOCK(X) =0, it is set to 1 and the transaction is allowed to access item X.
 When the transaction completed using the item, it issues an unlock_item(X) operation,
which sets LOCK(X) back to 0 (unlocks the item) so that X may be accessed by other
transactions.

Two values: locked (1) or unlocked (0)

 Cont’d

 Hence, a binary lock enforces mutual exclusion on the data item.

 Lock and unlock features eliminate the lost update problem because
the lock is not released until the WRITE statement is completed.
 Binary locks are too restrictive to yield optimal concurrency conditions

 Therefore, it is not used much in practice.

 2. Shared/Exclusive Locks (Read/Write
Locks)
 The labels “shared” and “exclusive” indicate the nature of the lock.
 An exclusive lock exists when access is reserved specifically for the
transaction that locked the object.
 The exclusive lock must be used when the potential for conflict exists.
 A shared lock exists when concurrent transactions are granted read access
on the basis of a common lock.
 A shared lock produces no conflict as long as all the concurrent transactions
are read-only.
 Cont’d
 Multiple-mode lock
 There are three locking operations: read_lock(X), write_lock(X), and unlock(X).
 A lock associated with an item X, LOCK(X), now has three possible states: read-locked,
write-locked or unlocked.
 A read-locked item is also called share-locked because other transactions are allowed to
read the item.
A write-locked item is called exclusive-locked because a single transaction exclusively holds
the lock on the item.
 Cont’d
 A shared lock is issued when a transaction wants to read data from the database and no
exclusive lock is held on that data item.
 An exclusive lock is issued when a transaction wants to update (write) a data item and
no locks are currently held on that data item by any other transaction.

 Shared locks allow several read transactions to read the same data item concurrently.

 The exclusive lock is granted if and only if no other locks are held on the data item.

 This condition is known as the mutual exclusive rule: only one transaction at a time
can own an exclusive lock on the same object.
 Cont’d
 Although the use of shared locks renders data access more efficient, a
shared/exclusive lock schema increases the lock manager’s overhead, for
several reasons:
1. The type of lock held must be known before a lock can be granted.
2. Three lock operations exist: READ_LOCK, WRITE_LOCK, and UNLOCK.
3. It allow a lock upgrade (from shared to exclusive) and a lock downgrade
(from exclusive to shared).
 Cont’d
 Example:- Transaction T1 transfer 100 birr to T2 and T2 wants to display(A+B)

Simple Lock
T1 T2
read_lock_X(A); read_lock_S (A);
read_item(A); read_item(A);
A:=A-100; unlock(A);
write_item(A); read_lock_S (B);
unlock(A); read_item(B);
read_lock_X(B); unlock(B);
read_item(B); Display(A+B);
B:=B+100;
write_lock(B);
unlock(B);
 Cont’d
 Example:- Show the following transaction in Simple Lock Protocol

T1 T2

Read (P)
P=P+5
Write (P)
Read(P)
P=P*3
Write (P)
Read(Q)
Q=Q+5
W(Q)
 Conversion of Locks
A Transaction is allowed under certain conditions to convert the lock from one state
to another.
 Upgrading: existing read lock to write lock
– Convert the lock from shared to exclusive by issuing write lock(X) after its read
lock(X).
– The transaction must be the only one that has the read lock or it must wait.
 Downgrading: existing write lock to read lock
– Convert the lock from exclusive to shared by issuing read_lock(X) after the
write_lock(X).
 Cont’d
Locks prevent data inconsistencies, but they can lead to two major
problems:
1. The resulting transaction schedule might not be serializable.
2. The schedule might create deadlocks. (A deadlock occurs when two
transactions wait indefinitely for each other to unlock data. )
To solve the above mentioned issues additional protocols concerning the
positioning of locking and unlocking operations are followed in every
transaction.
 Two-Phase Locking (2PL) to Ensure Serializability

Two-phase locking defines how transactions acquire and relinquish (release) locks.
Two-phase locking guarantees serializability.
 A transaction is said to follow the 2PL protocol if all locking operations precede the
first unlock operation of the transaction.
 The transaction is divided into two phases:
 Growing or Expanding phase (first phase) where new locks can be issued and
none can be released. Once all locks have been acquired, the transaction is in its
locked point.
 Shrinking phase (second phase) where existing locks can be released and cannot
obtain any new lock.
 Two-Phase Locking (2PL) to Ensure Serializability
 Example

With 2PL
T1
read_lock_S(A);
read_item(A);
read_lock_X(B);
read_item(A);
read_item(B);
B:=A+B;
unlock(A);
write_lock(B);
unlock(B):
 Two-Phase Locking (2PL) to Ensure Serializability
 Example
Without 2PL With 2PL
T1 T2 T1 T2
read_lock(Y); read_lock(X); read_lock(Y); read_lock(X);
read_item(Y); read_item(X); read_item(Y); read_item(X);
unlock(Y); unlock(X); write_lock(X ); write_lock(Y);
write_lock(X); write_lock(Y); unlock(Y); unlock(X);
read_item(X); read_item(Y); read_item(X); read_item(Y);
X:=X+Y; Y:=X+Y; X:=X+Y; Y:=X+Y;
write_item(X); write_item(Y); write_item(X); write_item(Y);
unlock(X): unlock(Y); unlock(X): unlock(Y);
 Cont’d
 2PL limits the concurrency.
 A transaction T may not be able to release an item X even after it is through
using it but needs to lock another item later.
 Another transaction that needs X has to wait even though T is done with X.
 The algorithm is called the Basic 2PL and there are many variations to it:
 Conservative 2PL
 Strict 2PL
 Rigorous 2PL
 Conservative/Static 2PL
 It requires a transaction to lock all the items it accesses before the transaction
begins execution (by pre-declaring its read and write sets).
 The read-set of a transaction is the set of all items that the transaction reads and
 The write-set is the set of all items that it writes.
 If any of the pre-declared items needed cannot be locked, the transaction does not
lock any item; instead, it waits until all the items are available for locking.
 It is difficult in practice because it is not possible in most cases to get the read
and write sets.
 The conservative 2PL is a deadlock-free protocol.
Example Example of Conservative 2PL
 Strict 2PL
 It is the most popular variation of 2PL in practice.
 It requires that a transaction T does not release any of its exclusive locks until
it commits or aborts.
 Strict 2PL is not a deadlock-free protocol.

T1
read_lock_S(A);
read_item(A);
read_lock_X(B);
unlock(A);
read_item(B);
write_item(B);
Commit;
unlock(B):
 Rigorous 2PL
 It is a more restrictive variation of Strict 2PL.

 It requires that a transaction T does not release any of its locks (shared or
exclusive) until it commits or aborts.
 It is easier to be implemented than the strict 2PL.
 Cont’d
 Now, let’s see the schedule below, tell me if this schedule can be locked using 2-PL, and if yes,
show how and what class of 2-PL does your answer belongs to.
T1 T2
1 Lock-S(A)
T1 T2 2 Read(A)
1 Read(A) 3 Lock-S(A)
2 Read(A) 4 Read(A)
3 Read(B) 5 Lock-X(B)
4 Write(B) 6 Read(B)
5 Commit 7 Write(B)
6 Read(B) 8 Unlock(A)
7 Write(B) 9 Commit
6 Commit 10 Unlock(B)
11 Lock-X(B)
12 Read(B)
13 Write(B)
14 Unlock(A)
14 Commit
Observe that our locks are released after Commit operation so 16 Unlock(B)
this satisfies Strict 2pl.2-PL protocol.
 Deadlocks

 A deadlock occurs when two transactions wait indefinitely for each other to
unlock data.

 For example, a deadlock occurs when two transactions, T1 and T2, exist in the
following mode
• T1 = access data items X and need Y
• T2 = access data items Y and need X
Note that deadlocks are possible only when one of the transactions wants to
obtain an exclusive lock on a data item.
No deadlock condition can exist among shared locks.
 Deadlocks

 The three basic techniques to control Deadlocks

1, Deadlock Prevention Protocols
2, Deadlock Detection Protocols
3, Timeouts
 Deadlock Prevention Protocols

 Using the conservative 2PL – locking all the data items before

starting the execution

 No waiting Protocols (NW)

 Using the concept of transaction Timestamps

 Deadlock Prevention Protocols

1, No Waiting
 If a transaction is unable to obtain a lock, it is immediately aborted and then
restarted after a certain time delay without checking if a deadlock will actually
occur or not.
 The protocol can cause transactions to abort and restart needlessly.

2, Transaction Timestamps :- Wait-Die and Wound-Wait

 Deadlock Prevention Protocols
 Transaction Timestamps

 It is used to decide if the transaction involved in a deadlock situation should wait, abort or
preempt(block) another transaction.

 The timestamp of a transaction T is TS(T) which is a unique identifier assigned to the

transaction T and is based on the order in which the transaction T is started.

 If T1 started before T2, then TS(T1) < TS(T2).

 Deadlock Prevention Protocols
 Wait-Die: If TS(Ti) < TS(Tj), then Ti is allowed to wait; otherwise abort Ti (Ti dies) and restart it
later with the same timestamp.
Ti Tj Tk

T1 T2 T3

Lock_X(A)

Lock_X(B)
Lock_X(A) lock Rollback

Lock_X(B)
.. Lock_X(A)

Wait Lock_X(B)

 Oldest Wait, newer Rollback and older gets the lock

 Deadlock Prevention Protocols
 Wound-Wait: If TS(Ti) < TS(Tj), then abort Tj (Ti wounds Tj ) and restart it later with the same
timestamp; otherwise Ti is allowed to wait.

Ti Tj Tk

T1 T2 T3

Lock_X(A)

Lock_X(B)
Lock_X(A) Rollback Wait

Lock_X(B)
Lock Lock_X(A)

Lock_X(B)

 Newer Wait, Older Rollback and oldest gets the lock

 Deadlock Detection
 The DBMS periodically tests the database for deadlocks. If a deadlock is found, one of
the transactions (the “victim m”) is aborted (rolled back and restarted) and the other
transaction continues.

 The concept is to not enforce any restrictions on executing the transactions, but check if
a deadlock actually exists.

 Wait-for graph is used to detect the state of deadlock.

 Wait for Graph
 One node for each currently executing transaction.
 If Ti is waiting to lock an item X that is currently locked by Tj, a directed edge from Ti
to Tj is created.

 If Tj releases the lock of item that Ti was waiting for, the directed edge is dropped from
the graph.

 If the graph has a cycle, the state of the deadlock exists.

 Selecting a transaction to be aborted is known as Victim Selection.

 Timeouts
 The technique used to kill the session based up on the system defined times.
 This method is practical because of its low overhead and simplicity.

 In this method, if a transaction waits for a period longer than a system-defined timeout
period, the system assumes that the transaction may be deadlocked and aborts it—
regardless of whether a deadlock actually exists or not.

 In Addition to serializability and deadlock problem Starvation may also occur when
implementing lock operations.
Concurrency Control Based on
Timestamp Ordering

49
 2. Concurrency Control Based on Timestamp Ordering

 A different approach that guarantees serializability involves using transaction timestamps

to order transaction execution for an equivalent serial schedule.
Timestamp of transaction T, TS(T) is a unique identifier created by the DBMS to identify
relatively starting time a transaction.
 Timestamp values are assigned in the order in which the transactions are submitted to
the system.
So a timestamp can be thought of as the transaction start time.
A larger timestamp value indicates a more recent event or operation.
Concurrency control techniques based on timestamp ordering do not use locks; hence,
deadlocks cannot occur.
 Cont’d
Timestamps can be generated in two ways
 Using a Counter Timestamp
 A counter that is incremented each time its value is assigned to a transaction and
are numbered 1, 2, 3, ... in this scheme.
 A computer counter has a finite maximum value, so the system must periodically
reset the counter to zero.
 Using Date Timestamps:
 The current date/time value of the system clock and ensure that no two timestamp
values are generated during the same tick of the clock.
 Timestamp Ordering Algorithm(TO)
 The idea for this scheme is to order the transactions based on their timestamps.
A schedule in which the transactions participate is then serializable, and the only
equivalent serial schedule permitted has the transactions in order of their timestamp values.
The algorithm must ensure that, for each item accessed by conflicting operations in the
schedule, the order in which the item is accessed does not violate the timestamp order
(TS(1) < TS(2) ).
associates with each database item X two timestamp (TS) values:
To do this, the TO algorithm associates with each database item X have two timestamp
(TS) values:-
Those are RTS(X) and WTS(X).
 Cont’d
1, RTS(X): The read timestamp of item X, which is the largest timestamp among
all the timestamps of transactions that have successfully read item X.

 RTS(X) = TS(T), where T is the last transaction that has read X successfully.

2, WTS(X): The write timestamp of item X, which is the largest of all the
timestamps of transactions that have successfully written item X.

 WTS(X) = TS(T), where T is the last transaction that has written X

successfully.
 Cont’d
 RTS(A)
=0 10 20 30 40  WTS(A)
Update T1=10 T1 T2 T3 T4 =0
Update T3=30 Read (A) Update T1=10
Therefore RTS(A)=30 Update T4=40
Write (A) Therefore WTS(A)=40
Read (A)

Write(A)
 Cont’d

There are two common timestamp ordering algorithm those are:-

A. Basic Timestamp Ordering
B. Strict Timestamp Ordering
 A. Basic Timestamp Ordering (TO)
 Utilizes Timestamps to guarantee serializability of concurrent
transactions.

 Whenever some transaction T tries to issue a read_item(X) or a

write_item(X) operation, the basic TO algorithm compares the
timestamp of T with RTS(X) and WTS(X) to ensure that the timestamp
order of transaction execution is not violated.
 Cont’d
 The concurrency control algorithm must check whether conflicting operations violate the
timestamp ordering in the following two cases:

 Case 1 (Read): Transaction T issues a read(X) operation

 If WTS(X) > TS(Ti) , then read(X) is rejected(roll back Ti) (as the TO rule is violated).

 [then a younger transaction has already written to the data item so abort and roll-back T and
reject the operation or Ti is an older Transaction then last Transaction that write the value of
X will request fail ]

 If TS(Ti) >= WTS(X) ,then execute read(X) of T and update RTS(X) to the largest of

TS(T).[Ti allowed to read updated value of X, Set RTS(X)=Max (RTS (X),TS(Ti))]

 Cont’d

 Case 2 (Write): Transaction T issues a write(X) operation

 If RTS(X) > TS(Ti) or if WTS(X) >TS(Ti) then write is rejected(roll back).

[then a younger/last transaction has already read/write the data item so abort and
roll-back T and reject the operation.]

 If TS(T) >= RTS(X) and TS(Ti) >=WTS(X), then execute write(X) of T and
update WTS(X) = TS(Ti).
 Two Case Example of TOA
T1 T2 T1 T2 T1 T2
TS(T1)=10 TS(T2)=20 TS(T1)=10 TS(T2)=20 TS(T1)=10 TS(T2)=20
Old Young Old Young Old Young

Read(A) Write(A) Write(A)

. .
Write(A) Read(A) . Write(A) .
.
Commit
rollback rollback Lost Update
 Example 1
 Apply Basic TO Algorithm by using Two Case of Timestamp Algorithm
T1 T2 T3 R(A) 0>100 F
TS(T1)=100 TS(T2)=200 TS(T3)=300
Read(A) 0,100
Read(B) R(B) 0>200 F
Write (C) 0,200
Read(B) W(C) 0>100
0>100F
A B C Read(C) 0 to 100
RTS 0 0 0
Write (B)
100 200 100
300 Write(A)

WTS 0 0 0
300 100
 Basic TO Algorithm Example
 Two transactions T1 and T2. Initially RTS=0 and WTS=0 for data items X, Y
 Timestamps are as follows: TS(T1)=10 and TS(T2)=20

T1 T2
TS(T1)=10 TS(T2)=20
1. A1 = Read(X)
2. A1 = A1 – k
3. Write(X, A1)
1. A1 = Read(X)
2. A1 = A1 * 1.01
3. Write(X, A1)
4. A2 = Read(Y)
5. A2 = A2 + k
6. Write(Y, A2)
4. A2 = Read(Y)
5. A2 = A2 * 1.01
6. Write(Y, A2)

 Discuss whether the following schedule is serializable or not? Justify your

answer using Basic TO Algorithm.
 Cont’d.
T1(10) T2(20)
RTS(X) : 10 1. A1 = Read(X)
WTS(X) : 10 2. A1 = A1 – k
RTS(Y) : 0 3. Write(X, A1)
WTS(Y) : 0 1. A1 = Read(X) RTS(X) : 20
2. A1 = A1* 1.01 WTS(X) : 20
3. Write(X, A1) RTS(Y) : 0
WTS(Y) : 0

RTS(X) : 20 4. A2 = Read(Y)
WTS(X) : 20 5. A2 = A2 + k
RTS(Y) : 10 6. Write(Y, A2)
WTS(Y) : 10 4. A2 = Read(Y) RTS(X) : 20
5. A2 = A2 * 1.01 WTS(X) : 20
6. Write(Y, A2) RTS(Y) : 20
WTS(Y) : 20
The schedule given above is serializable
 Example 2
• Discuss whether the following schedule is serializable or not? Justify your answer using
Basic TO Algorithm.
T1 T2
TS(T1)=10 TS(T2)=20
1. A1 = Read(X)
2. A1 = A1 – k
3. Write(X, A1)
1. A1 = Read(X)
2. A1 = A1* 1.01
3. Write(X, A1)
4. A2 = Read(Y)
5. A2 = A2 * 1.01
6. Write(Y, A2)
4. A2 = Read(Y)
5. A2 = A2 + k
6. Write(Y, A2)
 Cont’d

Advantages of Basic TO Algorithm

 Schedules are serializable (like 2PL protocols)

 No waiting for transaction, thus, no deadlocks!

 Cont’d

Disadvantages of Basic TO Algorithm

 Schedule may not be recoverable (read uncommitted data)

o Solution: Utilize Strict TO Algorithm.

 Starvation is possible (if the same transaction is continually

aborted and restarted)

o Solution: Assign new timestamp for aborted transaction

 B. Strict Timestamp Ordering

The Basic T.O algorithm guarantees serializability but not Recoverability.

The Strict Timestamp Ordering algorithm introduces recoverability.

Strict Schedule: A transaction can neither read nor write an uncommitted data
item X.

Strict Timestamp Ordering: Extend the accept cases of the Basic Timestamp
Ordering algorithm by adding the requirement that a commit occurs before T
proceeds with its operation. i.e.,
 Strict Timestamp Ordering

Case 1: Transaction T issues a read(X) operation:

 If WTS(X) < TS(Ti), then delay T until the transaction T’ that wrote X has
terminated (committed or aborted).
 Strict Timestamp Ordering
Case 2: Transaction T issues a write(X) operation:

 If RTS(X) <= TS(T) and WTS(X) <= TS(T), then delay T until the
transaction T’ that wrote and read X has terminated (committed or aborted).
Multi version Concurrency
Control

69
 3. Multi Version Concurrency Control
(MVCC)
When a MVCC database needs to update an item of data, it will not
overwrite the old data with new data, but instead mark the old data as
obsolete/outdated and add the newer version elsewhere.
Thus there are multiple versions stored, but only one is the latest.
This approach maintains a number of versions of a data item and allocates
the right version to a read operation of a transaction.
 Cont’d
 Unlike other mechanisms a read operation in this mechanism is never rejected.

 When any transaction writes an item it writes a new version and the old version
of the item is retained.

 When any transaction reads an item, appropriate version has to be provided

maintaining serializability.

Disadvantage

 More storage (RAM and Disk) is required to maintain multiple versions.

 Multi version technique based on timestamp ordering

Assume X1, X2, …, Xn are the version of a data item X created by a write operation of
transactions.

 Note: New version of Xi is created only by a write operation.

 With each Xi a RTS (read timestamp) and a WTS (write timestamp) are associated.

 RTS(Xi): The read timestamp of Xi is the largest of all the timestamps of

transactions that have successfully read version Xi .

 WTS(Xi): The write timestamp of Xi is the largest of all the timestamps of

transactions that have successfully written the value of version Xi.
 Cont’d
 Basic Idea: Works much like Basic TO with the difference that instead of WTS(X) and
RTS(X) we now utilize the highest WTS(Xi) and highest RTS(Xi) respectively.

 Whenever a transaction T is allowed to execute a write_item(X) operation, a new

version Xk+1 of item X is created, with

 WTS(Xk+1) = TS(T).

 RTS(Xk+1) = TS(T).

 When a transaction T is allowed to read the value of version X k, the value of

RTS(Xk) = largest of the current RTS(Xk) and TS(T).
 Cont’d

To ensure serializability, the following rules are used

 If transaction T issues read(X), find the version i of X that has the highest
WTS(Xi) of all versions of X that is also less than or equal to TS(T),

 Then accept the read and update the RTS(X) respectively.

 Cont’d

 If transaction T issues write(X) and highest WTS(Xi) also less than or

equal to TS(T), and highest RTS(Xi) less than or equal to TS(T), then create
a new version Xi and RTS(Xi )= WTS(Xi) = TS(T).
Optimistic Concurrency Control
ordering

76
 4. Optimistic Concurrency Control
ordering
 In optimistic concurrency control techniques no checking is done while the
transaction is executing.

 In Optimistic Concurrency Control, a schedule is checked against

serializability only at the time of commit.

 Transactions are aborted in case of non-serializable schedules.

 Cont’d
There are three phases for this concurrency control protocol:

1. Read & Execution phase: A transaction can read values of committed data
items from the database. However, updates are applied only to local copies
(versions) of the data items kept in the transaction workspace.

2. Validation phase: Checking is performed to ensure that serializability will

not be violated if the transaction updates are applied to the database.
 Cont’d.
3. Write phase:

 If the validation phase is successful, the transaction updates are applied to the database;

 otherwise, the updates are discarded and the transaction is restarted.

Note:

 The techniques are called optimistic because they assume that little interference will
occur and there is no need to do checking during transaction execution.
Thank you!