- Concurrency control manages simultaneous database operations to prevent interference. This avoids issues like lost updates, dirty reads, and incorrect summaries. - Lock-based protocols use locks to control concurrent access. Timestamp-based protocols assign timestamps to transactions to determine execution order. - The two-phase locking protocol acquires all locks in a "growing" phase before releasing any locks in a "shrinking" phase, ensuring serializability. Variations include strict two-phase locking and rigorous two-phase locking. - Timestamp-based protocols assign timestamps to transactions and check for conflicts between read/write operations and timestamps to ensure serial ordering. Thomas' write rule modifies checking for some write operations.

1. Concurrency Control

2. Concurrency Control
Concurrency control: the process of managing simultaneous
operations on the database without having them interfere with
each other.
Concurrent access to data is desirable when:
1. The amount of data is sufficiently great that at any given time
only fraction of the data can be in primary memory & rest
should be swapped from secondary memory as needed.
2. Even if the entire database can be present in primary memory,
there may be multiple processes.

3. Why we need Concurrency Control
Simultaneous execution of transactions over a shared database can
create several data integrity and consistency problems:
• Lost Updates.
• Temporary update or dirty read problem
• Incorrect summary

4. The Lost Update Problem
This problem occurs when two transactions that access the
same database items have their operations interleaved in a way
that makes the value of some database item incorrect.
Successfully completed update is overridden by another user.
Example:
• T1 withdraws £10 from an account with balance, initially £100.
• T2 deposits £100 into same account.
• Serially, final balance would be £190.
Loss of T2's update!!
This can be avoided by preventing T1 from reading balance
until after update.

5. The Temporary Update (or Dirty Read) Problem
 This problem occurs when one transaction updates a database item and then
the transaction fails for some reason. The updated item is accessed by another
transaction before it is changed back to its original value.
 Occurs when one transaction can see intermediate results of another
transaction before it has committed.
 Example:
T4 updates balance to £200 but it aborts, so balance should be back at
original value of £100.
T3 has read new value of balance (£200) and uses value as basis of £10
reduction, giving a new balance of £190, instead of £90.
 Problem avoided by preventing T3 from reading balance until after T4
commits or aborts.

6. The Incorrect Summary Problem
If one transaction is calculating an aggregate summary function on
a number of records while other transactions are updating some of
these records, the aggregate function may calculate some values
before they are updated and others after they are updated.
Occurs when transaction reads several values but second
transaction updates some of them during execution of first.
Example:
• T6 is totaling balances of account x (£100), account y (£50), and
account z (£25).
• Meantime, T5 has transferred £10 from balance x to balance z, so T6
now has wrong result (£10 too high)
Problem avoided by preventing T6 from reading balance x and
balance z until after T5 completed updates.

7. Why recovery is needed
Transactions should be durable, but we cannot prevent all
sorts of failures:
 System crashes
Power failures
Disk crashes
Physical problems and catastrophes

8. Mechanisms To Control the Concurrency:
There are two mechanisms by which we can control
concurrency according to our needs.
The first mechanism is that in which the user is responsible
to write the consistent concurrent transactions and they are
called Lock Based Protocols.
And the second mechanism is that in which system itself
tries to detect possible inconsistency during concurrent
execution and either the inconsistency recovered or
avoided. They are called Time Stamping Protocols.

9. Classification of concurrency control protocol
Lock based protocols
Binary locks
Shared / exclusive locks or read / write locks
2 phase locking protocol
Basic 2pl
Conservative 2pl or static 2pl
Strict 2pl
Rigorous 2 PL
Timestamp based protocol
Timestamp ordering protocol
Thomas write rule
Multiple granularity protocol
Multi version protocols

10. What is locking?
The concurrency problems can be solved by means of
concurrency control technique called locking.
A LOCK variable is associated with each data item which
is used to identify the status of the data item ( whether the
data is in use or not).
When a transaction T intends to access the data item, it
must first examines the associated LOCK.
If no other transaction holds the LOCK, the scheduler lock
the data item for T.
If another transaction T1 wants to access same data item
then the transaction T1 has to wait until T releases the lock.
Thus, at a time only one transaction can access the data
item.

11. Transaction Responsibility : Legal Transaction
To request lock before use of data item
To release lock after use of data item.
Example :
T1
Lock(A) // Locks the data item A
Read(A) // Read data item A
Write(A) // Write data item A
Unlock(A) // Unlock data item A
Lock(B) // Locks the data item B

12. Transaction Responsibility

13. Binary Locks
Binary lock can have 2 States or values
Locked (or 1) and
Unlocked (or 0)
We represent the current state( or value) of the lock associated
with data item X as LOCK(X).
Operations used with Binary Locking
1. lock_item : A transaction request access to an item by first
issuing a lock_item(X) operation.
If LOCK(X) =1 or L(X) : the transaction is forced to wait.
If LOCK(X) = 0 or U(x) : it is set to 1( the transaction locks the
item) and the transaction is a load to access item X.
2. unlock_item : After using the data item the transaction issues an
operation unlock(X), which sets the operation LOCK(X) to 0 i.e.
unlocks the data item so that X may be accessed by another
transactions.

14. Transaction Rules for Binary Locks
Every transaction must obey the following rules :
1. A transaction T must issue the lock(X) operation before
any read(X) or write(X) operations in T.
2. A transaction T must issue the unlock(X) operation after all
read(X) and write(X) operations in T.
3. If a transaction T already holds the lock on item X, then T
will not issue a lock(X) operation.
4. If a transaction does not holds the lock on item X, then T
will not issue an unlock(X) operation.

15. Example :

16. Points About Binary Locking :
A binary lock enforces mutual exclusion on the data item.
Serializability is not ensure i.e. may not eliminate non serializable
schedule.
The binary locks are simple but restrictive and so are not used in practice.
Implementation of Binary Locks :
Binary lock is implemented using 3 fields plus a queue for transactions
data waiting to access item.
The 3 fields are :
1. Data_item_name
2. LOCK
3. Locking_transaction
To keep track of and control access to locks, DBMS has a lock manager
subsystem. Items that are not in the lock table are considered to be
unlocked. The system maintains only those records for the items that are
currently lock in the lock table.

17. Shared and Exclusive Locks or
Read/Write Locks
Need of Shared/Read and Exclusive/Write Lock
The binary lock is too restrictive for data items because at most
one transaction can hold on a given item whether the transaction is
reading or writing.
To improve it we have shared and exclusive locks in which more
than one transaction can access the same item for reading
purposes. i.e. the read operations on the same item by different
transactions are not conflicting.
What are Shared and Exclusive Locks
In this types of lock, system supports two kinds of lock :
Exclusive(or Write) Locks and
Shared(or Read) Locks.

18. Shared Locks
If a transaction Ti has locked the data item A in shared mode,
then a request from another transaction Tj on A for :
Write operation on A : Denied. Transaction Tj has to wait until
transaction Ti unlock A.
Read operation on A : Allowed.
Example :
T
Shared(A)
Read(A) √
Write(A) ×

19. Exclusive Locks
If a transaction Ti has locked a data item a in exclusive
mode then request from some another transaction Tj for-
Read operation on A : Denied
Write operation on A : Denied

20. Example:

21. Concurrent Transaction

22. UNLOCKING IS DELAYED TO THE END OF
TRANSACTION
T3: lock-X(B)
read (B);
B:=B-50;
write(B);
lock-X(A);
read (A);
A:=A+50;
write(A);
unlock(B);
unlock(A);
T4: lock-S(A);
read (A);
lock-S(B);
read (B);
display(A+B)
unlock(A);
unlock(B);

23. Pitfalls of Lock-Based Protocols
 Consider the partial schedule
 Neither T3 nor T4 can make progress — executing lock-S(B) causes T4 to wait for T3 to release its lock
on B, while executing lock-X(A) causes T3 to wait for T4 to release its lock on A.
 Such a situation is called a deadlock.
 To handle a deadlock one of T3 or T4 must be rolled back
and its locks released.

24. Granting of locks
•T2 HOLDS S LOCK (Shared mode)
•T1-- requests X LOCK (Exclusive mode)
•T1 has to wait for T2 release the S Lock.
•T3 requests S LOCK . T3 will be granted S Lock
•But T1 has to wait till T3 finishes.
•T4 and T5 also requests SLOCK T4 and T5 will be granted Slock
• T1 has to wait for long till the completion of all other transaction.
•Thus transaction T1 may never make progress and it leads to starvation.
•To avoid starvation, when a transaction Ti requests a lock on a data item Q
in a particular mode M, the concurrency control manager grants the lock,
provided that
1. there is no other transaction holding a lock on data item Q in a mode
that conflicts with the mode M.
2. there is no other transaction waiting for a lock on Q, which had
made its lock request before Ti

25. Lock Conversions
Two-phase locking with lock conversions:
– First Phase:
can acquire a lock-S on item
can acquire a lock-X on item
can convert a lock-S to a lock-X (upgrade)
– Second Phase:
can release a lock-S
can release a lock-X
can convert a lock-X to a lock-S (downgrade)
This protocol assures serializability. But still relies on the
programmer to insert the various locking instructions.

26. The Two-Phase Locking Protocol
Protocol which ensures serializability is the two phase locking
protocol
Phase 1: Growing Phase
transaction may obtain locks
transaction may not release locks
Phase 2: Shrinking Phase
transaction may release locks
transaction may not obtain locks
The protocol assures serializability. It can be proved that the
transactions can be serialized in the order of their lock points (i.e.
the point where a transaction acquired its final lock).

27. The Two-Phase Locking Protocol (Cont.)
Two-phase locking does not ensure freedom from deadlocks
Cascading roll-back is possible under two-phase locking.
Basic 2PL
The technique of two phase locking is known as Basic 2PL.

28. Conservative 2PL( or Static 2PL)
In Conservative 2PL protocol, a transaction has to lock all the items
it access before the transaction begins execution. To avoid deadlocks,
we can use Conservative 2PL.
Advantages of Conservative 2PL :
1. No possibility of deadlock.
2. Ensure serializability.
Drawbacks of Conservative 2PL :
1. Less throughput.
2. Less resource utilisation because it holds the resources before the
transaction begins execution.
3. Less concurrency Prediction of all the required resources before
execution is also too complex.
4. However conservative 2pl is a deadlock free protocol but it is
difficult to use in practice. Starvation is possible.

29. Strict 2PL
A transaction T does not release any of its exclusive(write) locks until
after it commits or aborts.
Advantage:
1. Strict 2PL ensures serializability and the equivalent serial schedule is
based on the lock point.
Drawbacks:
1. Strict 2PL may not free from deadlock and starvation.

30. Rigorous 2PL Protocol
Transaction does not release any of its write locks and read locks
until after it commits or aborts.
Rigorous 2pl protocol ensures serializability and the equivalent
serial schedule is based on the order of COMMIT.

32. Timestamp based Protocol
The method for determining the serializabtility order is to select an
ordering among transactions in advance. The method is called a time
stamp ordering scheme
Each transaction is issued a timestamp when it enters the system. If
an old transaction Ti has time-stamp TS(Ti), a new transaction Tj is
assigned time-stamp TS(Tj) such that TS(Ti) <TS(Tj).
In order to assure such behavior, the protocol maintains for each
data Q two timestamp values:
W-timestamp(Q) is the largest time-stamp of any transaction
that executed write(Q) successfully.
R-timestamp(Q) is the largest time-stamp of any transaction
that executed read(Q) successfully.

33. Transactions with timestamps 10, 20, 30, 40, 50

34. Timestamp-Based Protocols (Cont.)
The timestamp ordering protocol ensures that any conflicting
read and write operations are executed in timestamp order.
Suppose a transaction Ti issues a read(Q)
1. If TS(Ti) ≤ W-timestamp(Q), then Ti needs to read a value of Q
that was already overwritten.
Hence, the read operation is rejected, and Ti is rolled back.
1. If TS(Ti)≥ W-timestamp(Q), then the read operation is
executed, and R-timestamp(Q) is set to max(R-timestamp(Q),
TS(Ti)).

35. Timestamp-Based Protocols
Suppose that transaction Ti issues write(Q).
1. If TS(Ti) < R-timestamp(Q), then the value of Q that Ti is
producing was needed previously, and the system assumed that
that value would never be produced.
Hence, the write operation is rejected, and Ti is rolled back.
1. If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an
obsolete value of Q.
Hence, this write operation is rejected, and Ti is rolled back.
1. Otherwise, the write operation is executed, and W-
timestamp(Q) is set to TS(Ti).

36. Thomas’s Write Rule
A modification of the basic TO algorithm, known as Thomas’s write rule, does
not enforce conflict serializability; but it rejects fewer write operations, by
modifying the checks for the write_item(X) operation as follows:
1. If read_TS(X) > TS(T), then abort and roll back T and reject the operation.
2. If write_TS(X) > TS(T), then do not execute the write operation but continue
processing. This is because some transaction with timestamp greater than TS(T)
—and hence after T in the timestamp ordering—has already written the value of
X. Hence, we must ignore the write_item(X) operation of T because it is already
outdated and obsolete. Notice that any conflict arising from this situation would
be detected by case (1).
3. If neither the condition in part (1) nor the condition in part (2) occurs, then
execute the write_item(X) operation of T and set write_TS(X) to TS(T).

37. Multiple Granularity Locking
All concurrency control techniques assumed that the database was
formed of a number of named data items. A database item could be
chosen to be one of the following:
A database record.
A field value of a database record.
A disk block.
A whole file.
The whole database.
The size of data items is often called the data item granularity.
Fine granularity refers to small item sizes, whereas coarse granularity
refers to large item sizes.

38. Intention Lock Modes
In addition to S and X lock modes, there are three additional lock
modes with multiple granularity:
intention-shared (IS): indicates explicit locking at a lower level of the tree
but only with shared locks.
intention-exclusive (IX): indicates explicit locking at a lower level with
exclusive or shared locks
shared and intention-exclusive (SIX): the sub tree rooted by that node is
locked explicitly in shared mode and explicit locking is being done at a
lower level with exclusive-mode locks.
intention locks allow a higher level node to be locked in S or X mode
without having to check all descendent nodes.

39. Compatibility Matrix with Intention Lock Modes
The compatibility matrix for all lock modes is:
IS IX S SIX X
IS
IX
S
SIX
X




×
  

×
×
× × × ×
×× ×
× ×
×
×
××

40. Multi version protocols
 Other protocols for concurrency control keep the old values of a data item when the item is updated.
These are known as multiversion concurrency control, because several versions (values) of an item
are maintained. When a transaction requires access to an item, an appropriate version is chosen to maintain
the serializability of the currently executing schedule, if possible. The idea is that some read operations that
would be rejected in other techniques can still be accepted by reading an older version of the item to
maintain serializability. When a transaction writes an item, it writes a new version and the old version of the
item is retained. Some multiversion concurrency control algorithms use the concept of view serializability
rather than conflict serializability.
 An obvious drawback of multiversion techniques is that more storage is needed to maintain multiple
versions of the database items. However, older versions may have to be maintained anyway—for example,
for recovery purposes. In addition, some database applications require older versions to be kept to
maintain a history of the evolution of data item values. The extreme case is a temporal database (see Chapter
23), which keeps track of all changes and the times at which they occurred. In such cases, there is no
additional storage penalty for multiversion techniques, since older versions are already maintained.