2. Multiple Granularity
Granularity is the size of data item  allowed to lock.
Multiple Granularity is the hierarchically breaking up the database into portions which are lockable and maintaining the track of what to be lock and how much to be lock so that it can be decided very quickly either to lock a data item or to unlock a data item.

3. Example of Multiple Granularity
Suppose a database is divided into files; files are divided into pages; pages are divided into records.
If there is a need to lock a record, then a transaction can easily lock it. But if there is a need to lock a file, the transaction have to lock firstly all the records one after another, then pages in that file and finally the file. So, there is a need to provide a mechanism for locking the files also which is provided by multiple granularity.

4. Granularity of locking (level in tree where locking is done):
When a transaction locks a node in the tree explicitly, it implicitly locks all the node's descendents in the same mode.
Granularity of locking (level in tree where locking is done):
fine granularity (lower in tree): high concurrency, high locking overhead
coarse granularity (higher in tree): low locking overhead, low concurrency

5. Why there is a Need to provide a Mechanism for Locking Files as well as Records ?
If we allow a mechanism for locking records only, then to lock a file, the transaction will have to lock all records in that file(say at one time) one after another, which is a wastage of time.
If we allow a mechanism for locking file only, then for a transaction to lock only five records, it will have to lock the whole file and therefore no other transaction will be able to use that file.
So, there is a need to provide the locks for files as well as records (provided by multiple granularity).

6. How do we Know that Some Transaction has Lock the Record or File or Database ? Because :
If some transaction has lock a record then it should not be allowed to lock the file or database.
Or if some transaction has lock a record of a file and there is a need to lock a record of another file, then it should be allowed to lock that record.

7. Multiversion Schemes
This concurrency control technique keeps 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.
 older versions may have to be maintained anyway—for example, for recovery purposes.

8. Multiversion Schemes
Multiversion schemes keep old versions of data item to increase concurrency.
Multiversion Timestamp Ordering
Multiversion Two-Phase Locking
Each successful write results in the creation of a new version of the data item written.
Use timestamps to label versions.
When a read(Q) operation is issued, select an appropriate version of Q based on the timestamp of the transaction, and return the value of the selected version.
reads never have to wait as an appropriate version is returned immediately.

9. Side effect:
Significantly more storage (RAM and disk) is required to maintain multiple versions. To check unlimited growth of versions, a garbage collection is run when some criteria is satisfied.

10. Database Concurrency Control
Multiversion technique based on timestamp ordering
This approach maintains a number of versions of a data item and allocates the right version to a read operation of a transaction.
Thus unlike other mechanisms a read operation in this mechanism is never rejected.
Side effects: Significantly more storage (RAM and disk) is required to maintain multiple versions. To check unlimited growth of versions, a garbage collection is run when some criteria is satisfied.

11. Database Concurrency Control
Multiversion technique based on timestamp ordering
This approach maintains a number of versions of a data item and allocates the right version to a read operation of a transaction.
Thus unlike other mechanisms a read operation in this mechanism is never rejected.
Side effects: Significantly more storage (RAM and disk) is required to maintain multiple versions. To check unlimited growth of versions, a garbage collection is run when some criteria is satisfied.

12. Database Concurrency Control
Multiversion technique based on timestamp ordering
Assume X1, X2, …, Xn are the version of a data item X created by a write operation of transactions. With each Xi a read_TS (read timestamp) and a write_TS (write timestamp) are associated.
read_TS(Xi): The read timestamp of Xi is the largest of all the timestamps of transactions that have successfully read version Xi.
write_TS(Xi): The write timestamp of Xi that wrote the value of version Xi.
A new version of Xi is created only by a write operation.

13. Dead Lock

14. Dead Lock
A deadlock is a condition wherein two or more tasks are waiting for each other in order to be finished but none of the task is willing to give up the resources that other task needs. In this situation no task ever gets finished and is in waiting state forever.

15. in the deadlock are either rolled back or restarted.
Deadlock is an unwanted situation that arises in a shared resource environment, where a process indefinitely waits for a resource that is held by another process.
For example, assume a set of transactions {T0, T1, T2, ...,Tn}.
T0 needs a resource X to complete its task.
Resource X is held by T1, and T1 is waiting for a resource Y, which is held by T2.
T2 is waiting for resource Z, which is held by T0.
Thus, all the processes wait for each other to release resources. In this situation, none of the processes can finish their task. This situation is known as a deadlock.
Deadlocks are not healthy for a system. In case a system is stuck in a deadlock, the transactions involved
in the deadlock are either rolled back or
restarted.

16. Coffman conditions
Coffman stated four conditions for a deadlock occurrence. A deadlock may occur if all the following conditions holds true.
Mutual exclusion condition: There must be at least one resource that cannot be used by more than one process at a time.
Hold and wait condition: A process that is holding a resource can request for additional resources that are being held by other processes in the system.
No preemption condition: A resource cannot be forcibly taken from a process. Only the process can release a resource that is being held by it.
Circular wait condition: A condition where one process is waiting for a resource that is being held by second process and second process is waiting for third process ….so on and the last process is waiting for the first process. Thus making a circular chain of waiting.

17. Deadlock Handling in Centralized Systems
There are three classical approaches for deadlock handling, namely −
Deadlock prevention.
Deadlock avoidance.
Deadlock detection and removal.

18. Deadlock Prevention
The deadlock prevention approach does not allow any transaction to acquire locks that will lead to deadlocks.
The convention is that when more than one transactions request for locking the same data item, only one of them is granted the lock.
One of the most popular deadlock prevention methods is pre-acquisition of all the locks.
In this method, a transaction acquires all the locks before starting to execute and retains the locks for the entire duration of transaction.
If another transaction needs any of the already acquired locks, it has to wait until all the locks it needs are available. Using this approach, the system is prevented from being deadlocked since none of the waiting transactions are holding any lock.

19. Deadlock Prevention
Removing mutual exclusion: All resources must be sharable that means at a time more than one processes can get a hold of the resources. That approach is practically impossible.
Removing hold and wait condition: This can be removed if the process acquires all the resources that are needed before starting out. Another way to remove this to enforce a rule of requesting resource when there are none in held by the process.
Preemption of resources: Preemption of resources from a process can result in rollback and thus this needs to be avoided in order to maintain the consistency and stability of the system.
Avoid circular wait condition: This can be avoided if the resources are maintained in a hierarchy and process can hold the resources in increasing order of precedence. This avoid circular wait. Another way of doing this to force one resource per process rule – A process can request for a resource once it releases the resource currently being held by it. This avoids the circular wait.

20. Deadlock Avoidance
Deadlock can be avoided if resources are allocated in such a way that it avoids the deadlock occurrence.
There are two algorithms for deadlock avoidance.
Wait/Die
Wound/Wait

21. Wait-Die Scheme
In this scheme, if a transaction requests to lock a resource (data item), which is already held with a conflicting lock by another transaction, then one of the two possibilities may occur −
If TS(Ti) < TS(Tj) − that is Ti, which is requesting a conflicting lock, is older than Tj − then Ti is allowed to wait until the data-item is available.
If TS(Ti) > TS(tj) − that is Ti is younger than Tj − then Ti dies. Ti is restarted later with a random delay but with the same timestamp.
This scheme allows the older transaction to wait but kills the younger one.

22. Wound-Wait Scheme
In this scheme, if a transaction requests to lock a resource (data item), which is already held with conflicting lock by some another transaction, one of the two possibilities may occur −
If TS(Ti) < TS(Tj), then Ti forces Tj to be rolled back − that is Ti wounds Tj. Tj is restarted later with a random delay but with the same timestamp.
If TS(Ti) > TS(Tj), then Ti is forced to wait until the resource is available.
This scheme, allows the younger transaction to wait; but when an older transaction requests an item held by a younger one, the older transaction forces the younger one to abort and release the item.

23. The table representation of resource allocation for each algorithm.
  Both of these algorithms take process age into consideration while determining the best possible way of resource allocation for deadlock avoidance.
Wait/Die
Wound/Wait
Older process needs a resource held by younger process
Older process waits
Younger process dies
Younger process needs a resource held by older process
Younger process waits

24. Wait-for Graph
This is a simple method available to track if any deadlock situation may arise. For each transaction entering into the system, a node is created.
When a transaction Ti requests for a lock on an item, say X, which is held by some other transaction Tj, a directed edge is created from Ti to Tj. If Tj releases item X, the edge between them is dropped and Ti locks the data item.
The system maintains this wait-for graph for every transaction waiting for some data items held by others. The system keeps checking if there's any cycle in the graph.

25. we can use any of the two following approaches −
First, do not allow any request for an item, which is already locked by another transaction. This is not always feasible and may cause starvation, where a transaction indefinitely waits for a data item and can never acquire it.
The second option is to roll back one of the transactions. It is not always feasible to roll back the younger transaction, as it may be important than the older one.
With the help of some relative algorithm, a transaction is chosen, which is to be aborted. This transaction is known as the victim and the process is known as victim selection.

26. Deadlock Detection and Removal
The deadlock detection and removal approach runs a deadlock detection algorithm periodically and removes deadlock in case there is one.
It does not check for deadlock when a transaction places a request for a lock. When a transaction requests a lock, the lock manager checks whether it is available.
If it is available, the transaction is allowed to lock the data item; otherwise the transaction is allowed to wait.
Since there are no precautions while granting lock requests, some of the transactions may be deadlocked.
To detect deadlocks, the lock manager periodically checks if the wait-for graph has cycles. If the system is deadlocked, the lock manager chooses a victim transaction from each cycle.
The victim is aborted and rolled back; and then restarted later.
Some of the methods used for victim selection are −
Choose the youngest transaction.
Choose the transaction with fewest data items.
Choose the transaction that has performed least number of updates.
Choose the transaction having least restart overhead.
Choose the transaction which is common to two or more cycles.