CONCURRENCY Concurrency is the tendency for different tasks to happen at the same time in a system ( mostly interacting with each other ) .   Parallel activities, that do not interact, have simple concurrency issues. It is when parallel activities interact or share the same resources that concurrency issues become important.

NEED FOR CONCURRENCY One transaction is reading several values from the common (shared data item) and the other transaction updates the record concurrently. The outcome of the first transaction will go wrong in this case.

CONCURRENCY CONTROL Activity of coordinating concurrent access to a database in a multi user database management system ( i.e ) managing simultaneous operations on the database without having interference with one another.

LOCK A lock is a mechanism to control concurrent access to a data item. If one transaction is accessing data item, then no other transaction can modify that data item. Data items can be locked in two modes : 1. exclusive (X) mode. Data item can be both read as well as written. X-lock is requested using lock-X instruction. 2. shared (S) mode. Data item can only be read. S-lock is requested using lock-S instruction. Lock requests are made to concurrency-control manager. Transaction can proceed only after request is granted.

The lock manager maintains a data-structure called a lock table to record granted locks and pending requests. Any number of transactions can hold shared locks on an item, but if any transaction holds an X-Lock on the item, then no other transaction may hold any lock on the item. If a lock cannot be granted, the requesting transaction is made to wait till all incompatible locks held by other transactions have been released. The lock is then granted.

LOCKING PROTOCOLS Set of rules followed by all transactions while requesting and releasing locks (i.e) while locking and unlocking the data items. Neither T3 nor T4 can make progress. Executing lock-S(B)–T4 wait for T3 to unlock B. Executing lock-X(A)-T3 wait for T4 to unlock A. Such a situation is called dead lock. To handle deadlock: One of T3 or T4 must release its lock Or must be rolled back.

Initially, a transaction is in growing phase. TWO PHASE LOCKING PROTOCOL 2PL protocol requires that each transaction issue lock or unlock requests in two phases: GROWING PHASE : a transaction may obtain locks but may not release any lock. SHRINKING PHASE : a transaction may release locks but may not obtain any new lock. Initially, a transaction is in growing phase. Acquires locks as much as it needs. Once it acquired enough locks, it releases a lock and enters shrinking phase.

STRICT TWO PHASE LOCKING A second transaction goes to wait state , if locked out by first. First come, First served will make sure the second one is next when the first releases lock. All locks requested by a transaction are held until the transaction is completed ( commits or aborts ), at which point the locks are released.

GRAPH BASED PROTOCOLS An alternative to two phase locking. Eg : Tree Protocol. Only exclusive locks are allowed. The first lock by Ti may be on any data item. Subsequently, a data D can be locked by Ti only if the parent of D is currently locked by Ti. Data items may be unlocked at any time. A data item that has been locked and unlocked by Ti cannot subsequently be relocked by Ti Transactions may have to lock the data items that they do not access.

INTENT LOCKING Only the intention of locking is expressed at the ancestor node of the required resource. The resource at the lower level is locked explicitly only when required. Allows a higher level node to be locked in S or X mode without having to check all descendant nodes.

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.

DEADLOCK System is deadlocked if there is a set of transactions such that every transaction in the set is waiting for another transaction in the set. STEPS TO HANDLE DEADLOCK: Deadlock Prevention: Ensures that the system will never enter in deadlock state. Deadlock Detection & Recovery: If the system enters in deadlock, it tries to recover from deadlock state.

DEADLOCK PREVENTION Two schemes of Deadlock Prevention: wait-die scheme — non-preemptive older transaction may wait for younger one to release data item. they are rolled back instead. a transaction may die several times before acquiring needed data item. wound-wait scheme — preemptive older transaction wounds (forces rollback) of younger transaction instead of waiting for it. Younger transactions may wait for older ones. may be fewer rollbacks than wait-die scheme.

RECOVERY FROM DEADLOCK When a deadlock detection algorithm determines that a deadlock exists, the system must recover from the deadlock. The most common solution is to rollback one or more transactions. THREE actions to be taken to recover from deadlock are: 1. Selection : The transaction which caused the deadlock is chosen as the victim and is rolled back to break the deadlock. 2. Rollback: Determines how far to roll back transaction. TOTAL ROLLBACK: Abort the transaction and restart it. PARTIAL ROLLBACK: Rollback as far as needed to break the deadlock.

3. Starvation: Its possible that, same transaction will be rolled back number of times to break the deadlock. As a result, this transaction never completes its designated task. Thus, there is starvation. To avoid this, we must ensure that transactions can be picked as a victim only a small number of times.