Starvation

Starvation is the situation when a transaction needs to wait for an indefinite period to
acquire a lock.

Following are the reasons for Starvation:

 When waiting scheme for locked items is not properly managed

 In the case of resource leak
 The same transaction is selected as a victim repeatedly

Deadlock

Deadlock refers to a specific situation where two or more processes are waiting for
each other to release a resource or more than two processes are waiting for the
resource in a circular chain.

Two Phase Locking Protocol

Two Phase Locking Protocol also known as 2PL protocol is a method of
concurrency control in DBMS that ensures serializability by applying a lock to the
transaction data which blocks other transactions to access the same data
simultaneously. Two Phase Locking protocol helps to eliminate the concurrency
problem in DBMS.

This locking protocol divides the execution phase of a transaction into three different
parts.

 In the first phase, when the transaction begins to execute, it requires permission
for the locks it needs.
 The second part is where the transaction obtains all the locks. When a
transaction releases its first lock, the third phase starts.
 In this third phase, the transaction cannot demand any new locks. Instead, it
only releases the acquired locks.
The Two-Phase Locking protocol allows each transaction to make a lock or unlock
request in two steps:

 Growing Phase: In this phase transaction may obtain locks but may not release
any locks.
 Shrinking Phase: In this phase, a transaction may release locks but not obtain
any new lock

It is true that the 2PL protocol offers serializability. However, it does not ensure that
deadlocks do not happen.

In the above-given diagram, you can see that local and global deadlock detectors are
searching for deadlocks and solve them with resuming transactions to their initial
states.

Timestamp-based Protocols
Timestamp based Protocol in DBMS is an algorithm which uses the System Time or
Logical Counter as a timestamp to serialize the execution of concurrent transactions.
The Timestamp-based protocol ensures that every conflicting read and write
operations are executed in a timestamp order.
The older transaction is always given priority in this method. It uses system time to
determine the time stamp of the transaction. This is the most commonly used
concurrency protocol.

Lock-based protocols help you to manage the order between the conflicting
transactions when they will execute. Timestamp-based protocols manage conflicts as
soon as an operation is created.

Example:

Suppose there are there transactions T1, T2, and T3.

T1 has entered the system at time 0010
T2 has entered the system at 0020
T3 has entered the system at 0030
Priority will be given to transaction T1, then transaction T2 and lastly Transaction T3.

Advantages:

 Schedules are serializable just like 2PL protocols

 No waiting for the transaction, which eliminates the possibility of deadlocks!

Disadvantages:

Starvation is possible if the same transaction is restarted and continually aborted

Validation Based Protocol

Validation based Protocol in DBMS also known as Optimistic Concurrency Control
Technique is a method to avoid concurrency in transactions. In this protocol, the local
copies of the transaction data are updated rather than the data itself, which results in
less interference while execution of the transaction.

The Validation based Protocol is performed in the following three phases:

1. Read Phase
2. Validation Phase
3. Write Phase
Read Phase
In the Read Phase, the data values from the database can be read by a transaction but
the write operation or updates are only applied to the local data copies, not the actual
database.

Validation Phase
In Validation Phase, the data is checked to ensure that there is no violation of
serializability while applying the transaction updates to the database.

Write Phase
In the Write Phase, the updates are applied to the database if the validation is
successful, else; the updates are not applied, and the transaction is rolled back.

Deadlock in DBMS
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.

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.

Deadlock detection
Resource scheduler is one that keeps the track of resources allocated to and requested by
processes. Thus, if there is a deadlock it is known to the resource scheduler. This is how a
deadlock is detected.

Once a deadlock is detected it is being corrected by following methods:

 Terminating processes involved in deadlock: Terminating all the processes

involved in deadlock or terminating process one by one until deadlock is resolved
can be the solutions but both of these approaches are not good. Terminating all
processes cost high and partial work done by processes gets lost. Terminating one
by one takes lot of time because each time a process is terminated, it needs to check
whether the deadlock is resolved or not. Thus, the best approach is considering
process age and priority while terminating them during a deadlock condition.
 Resource Preemption: Another approach can be the preemption of resources and
allocation of them to the other processes until the deadlock is resolved.

Deadlock Prevention : Deadlock prevention method is suitable for a large database. If the
resources are allocated in such a way that deadlock never occurs, then the deadlock can be
prevented.
 Mutual Exclusion - At least one resource must be held in a non-sharable mode; If any other
process requests this resource, then that process must wait for the resource to be released.
 Hold and Wait - A process must be simultaneously holding at least one resource and waiting
for at least one resource that is currently being held by some other process.
 No preemption - Once a process is holding a resource ( i.e. once its request has been granted
), then that resource cannot be taken away from that process until the process voluntarily
releases it.
 Circular Wait - A set of processes { P0, P1, P2, . . ., PN } must exist such that every P[ i ] is
waiting for P[ ( i + 1 ) % ( N + 1 ) ]. ( Note that this condition implies the hold-and-wait
condition, but it is easier to deal with the conditions if the four are considered separately. )
 Wait-Die scheme : In this scheme, if a transaction requests for a resource which is already held
with a conflicting lock by another transaction then the DBMS simply checks the timestamp of
both transactions. It allows the older transaction to wait until the resource is available for
execution.
Let's assume there are two transactions Ti and Tj and let TS(T) is a timestamp of any transaction
T. If T2 holds a lock by some other transaction and T1 is requesting for resources held by T2
then the following actions are performed by DBMS:
1. Check if TS(Ti) < TS(Tj) - If Ti is the older transaction and Tj has held some resource, then
Ti is allowed to wait until the data-item is available for execution. That means if the older
transaction is waiting for a resource which is locked by the younger transaction, then the older
transaction is allowed to wait for resource until it is available.
2. Check if TS(Ti) < TS(Tj) - If Ti is older transaction and has held some resource and if Tj is
waiting for it, then Tj is killed and restarted later with the random delay but with the same
timestamp.
Wound wait scheme : In wound wait scheme, if the older transaction requests for a resource
which is held by the younger transaction, then older transaction forces younger one to kill the
transaction and release the resource. After the minute delay, the younger transaction is restarted
but with the same timestamp.If the older transaction has held a resource which is requested by
the Younger transaction, then the younger transaction is asked to wait until older releases it.