UNIT-IV

TRANSACTION MANAGEMENT

A transaction is a set of logically related operations. For example, you are transferring money from your bank
account to your friend’s account, the set of operations would be like this:

Simple Transaction Example

1. Read your account balance

2. Deduct the amount from your balance
3. Write the remaining balance to your account
4. Read your friend’s account balance
5. Add the amount to his account balance
6. Write the new updated balance to his account

This whole set of operations can be called a transaction. Although I have shown you read, write and update
operations in the above example but the transaction can have operations like read, write, insert, update, delete.

In DBMS, we write the above 6 steps transaction like this:

Lets say your account is A and your friend’s account is B, you are transferring 10000 from A to B, the steps of the
transaction are:

1. R(A);
2. A = A - 10000;
3. W(A);
4. R(B);
5. B = B + 10000;
6. W(B);
In the above transaction R refers to the Read operation and W refers to the write operation.

Transaction failure in between the operations

Now that we understand what is transaction, we should understand what are the problems associated with it.

The main problem that can happen during a transaction is that the transaction can fail before finishing the all the
operations in the set. This can happen due to power failure, system crash etc. This is a serious problem that can leave
database in an inconsistent state. Assume that transaction fail after third operation (see the example above) then the
amount would be deducted from your account but your friend will not receive it. To solve this problem, we have
the following two operations

Commit: If all the operations in a transaction are completed successfully then commit those changes to the database
permanently.

Rollback: If any of the operation fails then rollback all the changes done by previous operations.
To ensure the integrity and consistency of data during a transaction (A transaction is a unit of program that
updates various data items, read more about it here), the database system maintains four properties. These
properties are widely known as ACID properties.

Atomicity -This property ensures that either all the operations of a transaction reflect in database or none.
The logic here is simple, transaction is a single unit, it can’t execute partially. Either it executes completely or
it doesn’t, there shouldn’t be a partial execution.

Let’s take an example of banking system to understand this:

Suppose Account A has a balance of 400$ & B has 700$. Account A is transferring 100$ to Account B.

This is a transaction that has two operations

a) Debiting 100$ from A’s balance
b) Creating 100$ to B’s balance.

Let’s say first operation passed successfully while second failed, in this case A’s balance would be 300$ while B
would be having 700$ instead of 800$. This is unacceptable in a banking system. Either the transaction should fail
without executing any of the operation or it should process both the operations. The Atomicity property ensures that.

There are two key operations are involved in a transaction to maintain the atomicity of the transaction.

Abort: If there is a failure in the transaction, abort the execution and rollback the changes made by the transaction.

Commit: If transaction executes successfully, commit the changes to the database.

Consistency -Database must be in consistent state before and after the execution of the transaction. This
ensures that there are no errors in the database at any point of time. Application programmer is responsible
for maintaining the consistency of the database.
Example:
A transferring 1000 dollars to B. A’s initial balance is 2000 and B’s initial balance is 5000.

Before the transaction:

Total of A+B = 2000 + 5000 = 7000$

After the transaction:

Total of A+B = 1000 + 6000 = 7000$

The data is consitendct before and after the execution of the transaction so this example maintains the consistency
property of the database.

Isolation- A transaction shouldn’t interfere with the execution of another transaction. To preserve the
consistency of database, the execution of transaction should take place in isolation (that means no other
transaction should run concurrently when there is a transaction already running).

For example account A is having a balance of 400$ and it is transferring 100$ to account B & C both. So we have
two transactions here. Let’s say these transactions run concurrently and both the transactions read 400$ balance, in
that case the final balance of A would be 300$ instead of 200$. This is wrong.

If the transaction were to run in isolation then the second transaction would have read the correct balance 300$
(before debiting 100$) once the first transaction went successful.

Durability- Once a transaction completes successfully, the changes it has made into the database should be
permanent even if there is a system failure. The recovery-management component of database systems
ensures the durability of transaction.

DBMS Transaction States Diagram

Lets discuss these states one by one.

Active State

As we have discussed in the DBMS transaction introduction that a transaction is a sequence of operations. If a
transaction is in execution then it is said to be in active state. It doesn’t matter which step is in execution, until
unless the transaction is executing, it remains in active state.

Failed State

If a transaction is executing and a failure occurs, either a hardware failure or a software failure then the transaction
goes into failed state from the active state.

Partially Committed State

As we can see in the above diagram that a transaction goes into “partially committed” state from the active state
when there are read and write operations present in the transaction.

A transaction contains number of read and write operations. Once the whole transaction is successfully executed, the
transaction goes into partially committed state where we have all the read and write operations performed on the
main memory (local memory) instead of the actual database.

The reason why we have this state is because a transaction can fail during execution so if we are making the changes
in the actual database instead of local memory, database may be left in an inconsistent state in case of any
failure. This state helps us to rollback the changes made to the database in case of a failure during execution.

Committed State

If a transaction completes the execution successfully then all the changes made in the local memory during partially
committed state are permanently stored in the database. You can also see in the above diagram that a transaction
goes from partially committed state to committed state when everything is successful.

Aborted State

As we have seen above, if a transaction fails during execution then the transaction goes into a failed state. The
changes made into the local memory (or buffer) are rolled back to the previous consistent state and the transaction
goes into aborted state from the failed state. Refer the diagram to see the interaction between failed and aborted state

DBMS Schedule and its types:

We know that transactions are set of instructions and these instructions perform operations on database. When
multiple transactions are running concurrently then there needs to be a sequence in which the operations are
performed because at a time only one operation can be performed on the database. This sequence of operations is
known as Schedule.

Lets take an example to understand what is a schedule in DBMS.

DBMS Schedule example

The following sequence of operations is a schedule. Here we have two transactions T1 & T2 which are running
concurrently.

This schedule determines the exact order of operations that are going to be performed on database. In this example,
all the instructions of transaction T1 are executed before the instructions of transaction T2, however this is not
always necessary and we can have various types of schedules which we will discuss in this article.

T1 T2
---- ----
R(X)
W(X)
R(Y)
R(Y)
R(X)
W(Y)
Types of Schedules in DBMS

We have various types of schedules in DBMS. Lets discuss them one by one.

Serial Schedule

In Serial schedule, a transaction is executed completely before starting the execution of another transaction. In other
words, you can say that in serial schedule, a transaction does not start execution until the currently running
transaction finished execution. This type of execution of transaction is also known as non-interleaved execution.
The example we have seen above is the serial schedule.

Lets take another example.

Serial Schedule example

Here R refers to the read operation and W refers to the write operation. In this example, the transaction T2 does not
start execution until the transaction T1 is finished.
T1 T2
---- ----
R(A)
R(B)
W(A)
commit
R(B)
R(A)
W(B)
commit
Strict Schedule

In Strict schedule, if the write operation of a transaction precedes a conflicting operation (Read or Write operation)
of another transaction then the commit or abort operation of such transaction should also precede the conflicting
operation of other transaction.

Lets take an example.

Strict Schedule example

Lets say we have two transactions Ta and Tb. The write operation of transaction Ta precedes the read or write
operation of transaction Tb, so the commit or abort operation of transaction Ta should also precede the read or write
of Tb.

Ta Tb
----- -----
R(X)
R(X)
W(X)
commit
W(X)
R(X)
commit
Here the write operation W(X) of Ta precedes the conflicting operation (Read or Write operation) of Tb so the
conflicting operation of Tb had to wait the commit operation of Ta.

Cascadeless Schedule

In Cascadeless Schedule, if a transaction is going to perform read operation on a value, it has to wait until the
transaction who is performing write on that value commits.

Cascadeless Schedule example

For example, lets say we have two transactions Ta and Tb. Tb is going to read the value X after the W(X) of Ta then
Tb has to wait for the commit operation of transaction Ta before it reads the X.

Ta Tb
----- -----
R(X)
W(X)
W(X)
commit
 R(X)
W(X)
commit
Recoverable Schedule

In Recoverable schedule, if a transaction is reading a value which has been updated by some other transaction then
this transaction can commit only after the commit of other transaction which is updating value.

Recoverable Schedule example

Here Tb is performing read operation on X after the Ta has made changes in X using W(X) so Tb can only commit
after the commit operation of Ta.

Ta Tb
----- -----
R(X)
W(X)
R(X)
W(X)
R(X)
commit
commit

DBMS Serializability

When multiple transactions are running concurrently then there is a possibility that the database may be left in an
inconsistent state. Serializability is a concept that helps us to check which schedules are serializable. A serializable
schedule is the one that always leaves the database in consistent state.

What is a serializable schedule?

A serializable schedule always leaves the database in consistent state. A serial schedule is always a serializable
schedule because in serial schedule, a transaction only starts when the other transaction finished execution. However
a non-serial schedule needs to be checked for Serializability.

A non-serial schedule of n number of transactions is said to be serializable schedule, if it is equivalent to the serial
schedule of those n transactions. A serial schedule doesn’t allow concurrency, only one transaction executes at a
time and the other starts when the already running transaction finished.

Types of Serializability

There are two types of Serializability.

1. Conflict Serializability
2. View Serializability

DBMS Conflict Serializability

In the DBMS Schedules guide, we learned that there are two types of schedules – Serial & Non-Serial. A Serial
schedule doesn’t support concurrent execution of transactions while a non-serial schedule supports concurrency. We
also learned in Serializability tutorial that a non-serial schedule may leave the database in inconsistent state so we
need to check these non-serial schedules for the Serializability.

Conflict Serializability is one of the type of Serializability, which can be used to check whether a non-serial
schedule is conflict serializable or not.

What is Conflict Serializability?

A schedule is called conflict serializable if we can convert it into a serial schedule after swapping its non-conflicting
operations.

Conflicting operations

Two operations are said to be in conflict, if they satisfy all the following three conditions:

1. Both the operations should belong to different transactions.

2. Both the operations are working on same data item.
3. At least one of the operation is a write operation.

Lets see some examples to understand this:

Example 1: Operation W(X) of transaction T1 and operation R(X) of transaction T2 are conflicting operations,
because they satisfy all the three conditions mentioned above. They belong to different transactions, they are
working on same data item X, one of the operation in write operation.

Example 2: Similarly Operations W(X) of T1 and W(X) of T2 are conflicting operations.

Example 3: Operations W(X) of T1 and W(Y) of T2 are non-conflicting operations because both the write
operations are not working on same data item so these operations don’t satisfy the second condition.

Example 4: Similarly R(X) of T1 and R(X) of T2 are non-conflicting operations because none of them is write
operation.

Example 5: Similarly W(X) of T1 and R(X) of T1 are non-conflicting operations because both the operations
belong to same transaction T1.

Conflict Equivalent Schedules

Two schedules are said to be conflict Equivalent if one schedule can be converted into other schedule after swapping
non-conflicting operations.

Conflict Serializable check

Lets check whether a schedule is conflict serializable or not. If a schedule is conflict Equivalent to its serial schedule
then it is called Conflict Serializable schedule. Lets take few examples of schedules.
Example of Conflict Serializability

Lets consider this schedule:

T1 T2
----- ------
R(A)
R(B)
R(A)
R(B)
W(B)
W(A)
To convert this schedule into a serial schedule we must have to swap the R(A) operation of transaction T2 with the
W(A) operation of transaction T1. However we cannot swap these two operations because they are conflicting
operations, thus we can say that this given schedule is not Conflict Serializable.

Lets take another example:

T1 T2
----- ------
R(A)
R(A)
R(B)
W(B)
R(B)
W(A)
Lets swap non-conflicting operations:

After swapping R(A) of T1 and R(A) of T2 we get:

T1 T2
----- ------
R(A)
R(A)
R(B)
W(B)
R(B)
W(A)
After swapping R(A) of T1 and R(B) of T2 we get:

T1 T2
----- ------
R(A)
R(B)
R(A)
W(B)
R(B)
W(A)
After swapping R(A) of T1 and W(B) of T2 we get:
T1 T2
----- ------
R(A)
R(B)
W(B)
R(A)
R(B)
W(A)
We finally got a serial schedule after swapping all the non-conflicting operations so we can say that the given
schedule is Conflict Serializable.

In the last tutorial, we learned Conflict Serializability. In this article, we will discuss another type of serializability
which is known as View Serializability.

What is View Serializability?

View Serializability is a process to find out that a given schedule is view serializable or not.

To check whether a given schedule is view serializable, we need to check whether the given schedule is View
Equivalent to its serial schedule. Lets take an example to understand what I mean by that.

Given Schedule:

T1 T2
----- ------
R(X)
W(X)
R(X)
W(X)
R(Y)
W(Y)
R(Y)
W(Y)
Serial Schedule of the above given schedule:
As we know that in Serial schedule a transaction only starts when the current running transaction is finished. So the
serial schedule of the above given schedule would look like this:

T1 T2
----- ------
R(X)
W(X)
R(Y)
W(Y)
R(X)
W(X)
R(Y)
W(Y)
If we can prove that the given schedule is View Equivalent to its serial schedule then the given schedule is
called view Serializable.
Why we need View Serializability?

We know that a serial schedule never leaves the database in inconsistent state because there are no concurrent
transactions execution. However a non-serial schedule can leave the database in inconsistent state because there are
multiple transactions running concurrently. By checking that a given non-serial schedule is view serializable, we
make sure that it is a consistent schedule.

You may be wondering instead of checking that a non-serial schedule is serializable or not, can’t we have serial
schedule all the time? The answer is no, because concurrent execution of transactions fully utilize the system
resources and are considerably faster compared to serial schedules.

View Equivalent

Lets learn how to check whether the two schedules are view equivalent.

Two schedules T1 and T2 are said to be view equivalent, if they satisfy all the following conditions:

1. Initial Read: Initial read of each data item in transactions must match in both schedules. For example, if
transaction T1 reads a data item X before transaction T2 in schedule S1 then in schedule S2, T1 should read X
before T2.

Read vs Initial Read: You may be confused by the term initial read. Here initial read means the first read operation
on a data item, for example, a data item X can be read multiple times in a schedule but the first read operation on X
is called the initial read. This will be more clear once we will get to the example in the next section of this same
article.

2. Final Write: Final write operations on each data item must match in both the schedules. For example, a data item
X is last written by Transaction T1 in schedule S1 then in S2, the last write operation on X should be performed by
the transaction T1.

3. Update Read: If in schedule S1, the transaction T1 is reading a data item updated by T2 then in schedule S2, T1
should read the value after the write operation of T2 on same data item. For example, In schedule S1, T1 performs a
read operation on X after the write operation on X by T2 then in S2, T1 should read the X after T2 performs write on
X.

View Serializable

If a schedule is view equivalent to its serial schedule then the given schedule is said to be View Serializable. Lets
take an example.
View Serializable Example

Lets check the three conditions of view serializability:

Initial Read-In schedule S1, transaction T1 first reads the data item X. In S2 also transaction T1 first reads the
data item X.

Lets check for Y. In schedule S1, transaction T1 first reads the data item Y. In S2 also the first read operation on Y
is performed by T1.

We checked for both data items X & Y and the initial read condition is satisfied in S1 & S2.

Final Write-In schedule S1, the final write operation on X is done by transaction T2. In S2 also transaction T2
performs the final write on X.

Lets check for Y. In schedule S1, the final write operation on Y is done by transaction T2. In schedule S2, final
write on Y is done by T2.

We checked for both data items X & Y and the final write condition is satisfied in S1 & S2.

Update Read-In S1, transaction T2 reads the value of X, written by T1. In S2, the same transaction T2 reads the
X after it is written by T1.

In S1, transaction T2 reads the value of Y, written by T1. In S2, the same transaction T2 reads the value of Y after it
is updated by T1.

The update read condition is also satisfied for both the schedules.

Result: Since all the three conditions that checks whether the two schedules are view equivalent are satisfied in this
example, which means S1 and S2 are view equivalent. Also, as we know that the schedule S2 is the serial schedule
of S1, thus we can say that the schedule S1 is view serializable schedule .
 Recoverability of Schedule in DBMS

In this guide, you will learn a very important concept in DBMS: Recoverability of Schedule. There are times when
few transactions in a schedule fail, due to a software or hardware issue. In that case, it becomes important to rollback
these failed transactions along with those successful transactions that have used the value updated by failed
transactions.

What is an Irrecoverable Schedule?

A schedule that cannot be rolled back because some transactions already used COMMIT to make the changes
permanent in database and these transactions have used values produced by the failed transactions. These types of
schedules are called irrecoverable schedules.

For example: In this example, we have a schedule that contains two transactions T1 and T2. Transaction T1 reads X
and make changes in the value of X and then writes the updated value of X.

This updated value of X is read by transaction T2, which then did some change in X and finally write the value of X
and used COMMIT statement to make the changes permanent.

After the changes are made permanent by transaction T2, the transaction T1 failed and it had to be rolled back but
the problem here is that T2 has already used commit statement so it cannot be rolled back. This is why this
schedule is irrecoverable because it cannot be successfully rolled back even after the failure of one of the
transaction.

T1 T2
---- ----
Read(X)
X = + 20
Write (X)
Read(X)
X = X + 100
Write(X)
Commit

Failed!
Rollback
What is a Recoverable Schedule?

A schedule that can be successfully rolled back in case of any failure is known as recoverable Schedule.

For example: Let’s take the same example that we have seen above with some modifications. Here we have moved
the commit statement in transaction T2 after the commit statement in transaction T1.

T1 T2
---- ----
Read(X)
X = + 20
Write (X)
Read(X)
X = X + 100
Write(X)
Commit
Commit
Now let’s consider some cases of failure to understand whether this schedule can be successfully rolled back.

Case 1: When T1 fails just before the commit statement. In this case both the transactions can be rolled back as
none of the transactions used COMMIT statement before the failure point in schedule.

T1 T2
---- ----
Read(X)
X = + 20
Write (X)
Read(X)
X = X + 100
Write(X)
Failed!
Commit
Commit
Case 2: Let’s say T2 failed after the commit statement in T1. This is also recoverable as the T2 can be rolled back
and T1 didn’t read value of X after write(X) in T1 so no bad read operation here, so no need to rollback the T1 in
this case.

T1 T2
---- ----
Read(X)
X = + 20
Write (X)
Read(X)
X = X + 100
Write(X)
Commit
Failed!
Commit
You can also try to put failure points in some places in this schedule other than the above two cases, you will find
that the schedule is recoverable.

Failure Classification in DBMS

In DBMS there are several transactions running in a specified schedule. However sometimes these transactions fail
due to several reasons. In previous tutorial, we learned how to identify a recoverable schedule. In this guide, we will
discuss the types of failures that can occur in DBMS.

Failures in DBMS are classified as follows:

 1. Transaction failure
2. Underlying System crash
3. Data transfer fail

1. Transaction Failure-A transaction is a set of statements, if a transaction fails it means there is a statement in the
transaction which is not able to execute. This can happen due to various reasons such as:

Logical Error: If the logic used in the statement itself is wrong, it can be fail.

System Error: When the transaction is executing but due to a fault in system, the transaction fails abruptly. For
example: Deadlock condition in transaction can result in System error.

2. Underlying System Crash-The system on which the transactions are running can crash and that can result in
failure of currently running transactions.

System can crash due to various reasons such as:

 Power supply disruptions

 Software issues such as Operating system issues
 Hardware issues

3. Hard-disk fail-Hard-disk fail can also cause transaction failure. When transactions are reading and writing data
into the disk, the failure in an underlying disk can cause failure of currently running transaction. This is because
transactions are unable to read and write data in disks due to disk not working properly. This can result in loss of
data as well.

There can be several reasons of a disk failure such as: formation of bad sectors in disk, corruption of disk, viruses,
not enough resources available on disk.

Log-Based Recovery in DBMS

In the previous chapters, you learned how to identify a recoverable schedule and what kind of failures can occur in
DBMS. In this chapter, you will learn how to recover a failed transaction using Log-based recovery in DBMS.
When a transaction fails, it is important to rollback the transaction so that changes made by failed transaction
doesn’t store in the database, this is important to maintain the integrity of database.

What is log-based recovery in DBMS?

1. As the name suggests, log is a sequence of records that is maintained in a stable storage devices to note down
all the changes made by transactions in a sequential manner. This log is used to recover the transaction in
case of failure.
2. Any operation performed by transaction on database is recorded in the log.
3. It is important to record the log before the actual operation performed on the database, this make sure that if
an operation fail, it is already recorded in the log.

How the logs are maintained?

Let’s take an example to understand the log-based recovery in DBMS:

A transaction T1 is modifying the Department of an employee, for this operation, the following log is maintained:
Log entry to mark the start of the transaction:

<T1, Start>
Just before the transaction modifies the department of the employee from “Sales” To “Marketing”, the following log
is maintained:

<T1, Department, 'Sales', 'Marketing' >

Log entry to mark the successful end of the transaction:

<T1, Commit>
Logs for different database modification approaches

There are two database modification approaches used by the transactions. Here we will learn how the logs are
maintained for each approach:

1. Deferred Database Modification-In this approach, the transaction does not commit the changes the
database, until it is completed successfully.

In this approach, all the logs are created at once and stored in the database.

2. Immediate Database Modification-In this approach, the transaction make change immediately after an
operation is performed by the transaction.

In this approach, logs are recorded just before the transaction is going to perform an operation in database.

Recovery using Log Records

In case of a transaction failure, the log is referenced to recover the transaction and rollback or redone all the
changes done by the transaction.

 If the log contains the entry <Tn, Start> and <Tn, Commit> or <Tn, Start> and <Tn, Abort> then the
transaction Tn needs to be redone based on the log entries for each operation recorded in the log.
 If the log contains the entry <Tn, Start> but doesn’t contain an entry for <Tn, Commit> or <Tn, Abort> then
the transaction needs to be rolled back.

What is a checkpoint?

 Checkpoint is like a bookmark in the transaction that helps us rollback a transaction till a certain point.
 These are really useful when a transaction performs several operations. If such transaction fail at any point of
time, instead of undoing the whole transaction, we can rollback to a certain checkpoint.
 We can have more than one checkpoint in a transaction. These checkpoints can be given any name so it’s
easier to identify the particular point in the transaction and rollback to a certain point in case of failure.
 You can say that by using checkpoints, you can divide the transaction in smaller parts. Once a checkpoint is
reached, the changes are made permanent in the database till that point and the log entries are removed. This
is because that part of the transaction is successfully completed so there is no need to roll back or redone,
thus no need to maintain those logs.
 A checkpoint represents a point till which all transactions are completed and database is in consistent state.
Recovery using Checkpoint

Let’s understand how to recover a failed transaction using checkpoint.

 The recovery system reads the log file in reverse (from end to start).
 Recovery system maintains two files: one is redo-list file and second is undo-list file. One or both of these
files are used to recover a failed transaction.
 If the recovery system finds a log entry with <Tn, Start> and <Tn, Commit> or just <Tn, Commit>, it puts
the transaction in the redo-list. This is because a commit statement represents that some of transactions in
this schedule are made permanent using commit statement, so it becomes important to redone the failed
transactions.
 If the recovery system finds a log entry with <Tn, Start> but no entry with <Tn, commit> or <Tn, Abort> , it
puts the transaction in undo-list. This is because no transaction made the changes permanent in the database
as no commit statements found, in this case the transaction can be rolled back by putting it in undo-list.

Example:

In the following diagram you can see a schedule with three transactions T1, T2 and T3. Since the log entries are
removed once a checkpoint is found, the entry <T1, Start> is not in the log as it is before the checkpoint and the log
is cleared at checkpoint. The entries that are there in the log are <T1, Commit>, <T2, Start>, <T2, Commit> and
<T3, Start>. The entry <T3, Commit> is not in the log because the transaction is failed before that.

So based on the rules that we have seen above, T1 and T2 are put in redo-list as <T1, Commit> and <T2,
Commit> present in log file. Transaction T3 is put in undo-list as <T3, Start> is found but no entry for <T3,
Commit> or <T3, Abort>.
 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 Handling

Ignore the deadlock (Ostrich algorithm)

Did that made you laugh? You may be wondering how ignoring a deadlock can come under deadlock handling. But
to let you know that the windows you are using on your PC, uses this approach of deadlock handling and that is
reason sometimes it hangs up and you have to reboot it to get it working. Not only Windows but UNIX also uses this
approach.

The question is why? Why instead of dealing with a deadlock they ignore it and why this is being called as
Ostrich algorithm?

Well! Let me answer the second question first, This is known as Ostrich algorithm because in this approach we
ignore the deadlock and pretends that it would never occur, just like Ostrich behavior “to stick one’s head in the
sand and pretend there is no problem.”
Let’s discuss why we ignore it: When it is believed that deadlocks are very rare and cost of deadlock handling is
higher, in that case ignoring is better solution than handling it. For example: Let’s take the operating system
example – If the time requires handling the deadlock is higher than the time requires rebooting the windows then
rebooting would be a preferred choice considering that deadlocks are very rare in windows.

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

We have learnt that if all the four Coffman conditions hold true then a deadlock occurs so preventing one or more of
them could prevent the deadlock.

 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.

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

Here is 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 dies Younger process waits