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:
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.
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 Operations used with Binary Locking
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 :
A transaction T must issue the lock(X) operation before any read(X) or write(X) operations in T.
A transaction T must issue the unlock(X) operation after all read(X) and write(X) operations in T.
If a transaction T already holds the lock on item X, then T will not issue a lock(X) operation.
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 :
Data_item_name
LOCK
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
there is no other transaction holding a lock on data item Q in a mode that conflicts with the mode M.
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 :
No possibility of deadlock.
Ensure serializability.
Drawbacks of Conservative 2PL :
Less throughput.
Less resource utilisation because it holds the resources before the transaction begins execution.
Less concurrency Prediction of all the required resources before execution is also too complex.
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:
Strict  2PL ensures serializability and the equivalent serial schedule is based on the lock point.
Drawbacks:
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)
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.
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).
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.
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.
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  

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.