UNIT-4 (Notes)

Introduction to Transaction in DBMS


In Database Management Systems (DBMS), a transaction is a fundamental concept
representing a set of logically related operations executed as a single
unit. Transactions are essential for handling user requests to access and modify
database contents, ensuring the database remains consistent and reliable despite
various operations and potential interruptions.
In this article, we will discuss what a transaction means, various operations of
transactions, transaction states, and properties of transactions in DBMS.
What does a Transaction mean in DBMS?
 Transaction in Database Management Systems (DBMS) can be defined as a set
of logically related operations.
 It is the result of a request made by the user to access the contents of
the database and perform operations on it.
 It consists of various operations and has various states in its completion journey.
 It also has some specific properties that must be followed to keep the database
consistent.
Operations of Transaction
A user can make different types of requests to access and modify the contents of a
database. So, we have different types of operations relating to a transaction. They are
discussed as follows:
i) Read(X)
 A read operation is used to read the value of X from the database and store it in a
buffer in the main memory for further actions such as displaying that value.
 Such an operation is performed when a user wishes just to see any content of the
database and not make any changes to it. For example, when a user wants to
check his/her account’s balance, a read operation would be performed on user’s
account balance from the database.
ii) Write(X)
 A write operation is used to write the value to the database from the buffer in the
main memory. For a write operation to be performed, first a read operation is
performed to bring its value in buffer, and then some changes are made to
it, e.g. some set of arithmetic operations are performed on it according to the user’s
request, then to store the modified value back in the database, a write operation is
performed.
 For example, when a user requests to withdraw some money from his account, his
account balance is fetched from the database using a read operation, then the
amount to be deducted from the account is subtracted from this value, and then the
obtained value is stored back in the database using a write operation.
iii) Commit
 This operation in transactions is used to maintain integrity in the database. Due to
some failure of power, hardware, or software, etc., a transaction might get
interrupted before all its operations are completed. This may cause ambiguity in
the database, i.e. it might get inconsistent before and after the transaction.
 To ensure that further operations of any other transaction are performed only after
work of the current transaction is done, a commit operation is performed to the
changes made by a transaction permanently to the database.
iv) Rollback
 This operation is performed to bring the database to the last saved state when any
transaction is interrupted in between due to any power, hardware, or software
failure.
 In simple words, it can be said that a rollback operation does undo the operations
of transactions that were performed before its interruption to achieve a safe state of
the database and avoid any kind of ambiguity or inconsistency.
Transaction Schedules
When multiple transaction requests are made at the same time, we need to decide their
order of execution. Thus, a transaction schedule can be defined as a chronological
order of execution of multiple transactions.
There are broadly two types of transaction schedules discussed as follows:
i) Serial Schedule
 In this kind of schedule, when multiple transactions are to be executed, they are
executed serially, i.e. at one time only one transaction is executed while others
wait for the execution of the current transaction to be completed. This ensures
consistency in the database as transactions do not execute simultaneously.
 But, it increases the waiting time of the transactions in the queue, which in turn
lowers the throughput of the system, i.e. number of transactions executed per time.
 To improve the throughput of the system, another kind of schedule are used which
has some more strict rules which help the database to remain consistent even when
transactions execute simultaneously.
ii) Non-Serial Schedule
 To reduce the waiting time of transactions in the waiting queue and improve the
system efficiency, we use nonserial schedules which allow multiple transactions to
start before a transaction is completely executed. This may sometimes result in
inconsistency and errors in database operation.
 So, these errors are handled with specific algorithms to maintain the consistency of
the database and improve CPU throughput as well.
 Non-serial schedules are also sometimes referred to as parallel schedules, as
transactions execute in parallel in these kinds of schedules.
Serializable
 Serializability in DBMS is the property of a nonserial schedule that determines
whether it would maintain the database consistency or not.
 The nonserial schedule which ensures that the database would be consistent after
the transactions are executed in the order determined by that schedule is said to be
Serializable Schedules.
 The serial schedules always maintain database consistency as a transaction starts
only when the execution of the other transaction has been completed under it.
 Thus, serial schedules are always serializable.
 A transaction is a series of operations, so various states occur in its completion
journey. They are discussed as follows:
i) Active
 It is the first stage of any transaction when it has begun to execute. The execution
of the transaction takes place in this state.
 Operations such as insertion, deletion, or updation are performed during this state.
 During this state, the data records are under manipulation and they are not saved to
the database, rather they remain somewhere in a buffer in the main memory.
ii) Partially Committed
 This state of transaction is achieved when it has completed most of the operations
and is executing its final operation.
 It can be a signal to the commit operation, as after the final operation of the
transaction completes its execution, the data has to be saved to the database
through the commit operation.

 If some kind of error occurs during this state, the transaction goes into a failed
state, else it goes into the Committed state.
iii) Commited
This state of transaction is achieved when all the transaction-related operations have
been executed successfully along with the Commit operation, i.e. data is saved into
the database after the required manipulations in this state. This marks the successful
completion of a transaction.
iv) Failed
 If any of the transaction-related operations cause an error during the active or
partially committed state, further execution of the transaction is stopped and it is
brought into a failed state. Here, the database recovery system makes sure that the
database is in a consistent state.
v) Aborted
If the error is not resolved in the failed state, then the transaction is aborted and a
rollback operation is performed to bring database to the the last saved consistent state.
When the transaction is aborted, the database recovery module either restarts the
transaction or kills it.
The illustration below shows the various states that a transaction may encounter in its
completion journey.

Transaction in DBMS

Properties of Transaction
 As transactions deal with accessing and modifying the contents of the database,
they must have some basic properties which help maintain the consistency and
integrity of the database before and after the transaction. Transactions follow 4
properties, namely, Atomicity, Consistency, Isolation, and Durability.
 Generally, these are referred to as ACID properties of transactions in DBMS.
ACID is the acronym used for transaction properties. A brief description of each
property of the transaction is as follows.
i) Atomicity
 This property ensures that either all operations of a transaction are executed or it is
aborted. In any case, a transaction can never be completed partially.
 Each transaction is treated as a single unit (like an atom). Atomicity is achieved
through commit and rollback operations, i.e. changes are made to the database
only if all operations related to a transaction are completed, and if it gets
interrupted, any changes made are rolled back using rollback operation to bring the
database to its last saved state.
ii) Consistency
 This property of a transaction keeps the database consistent before and after a
transaction is completed.
 Execution of any transaction must ensure that after its execution, the database is
either in its prior stable state or a new stable state.
 In other words, the result of a transaction should be the transformation of a
database from one consistent state to another consistent state.
 Consistency, here means, that the changes made in the database are a result of
logical operations only which the user desired to perform and there is not any
ambiguity.
iii) Isolation
 This property states that two transactions must not interfere with each other, i.e. if
some data is used by a transaction for its execution, then any other transaction can
not concurrently access that data until the first transaction has completed.
 It ensures that the integrity of the database is maintained and we don’t get any
ambiguous values. Thus, any two transactions are isolated from each other.
 This property is enforced by the concurrency control subsystem of DBMS.
iv) Durability
 This property ensures that the changes made to the database after a transaction is
completely executed, are durable.
 It indicates that permanent changes are made by the successful execution of a
transaction.
 In the event of any system failures or crashes, the consistent state achieved after
the completion of a transaction remains intact. The recovery subsystem of DBMS
is responsible for enforcing this property.
Conclusion
Transactions in DBMS are pivotal in maintaining the integrity and consistency of the
database through a series of well-defined operations and states. From the initial
execution of operations to handling errors and ensuring consistency, transactions must
adhere to the ACID properties—Atomicity, Consistency, Isolation, and Durability.
These properties guarantee that transactions are processed reliably and that the
database remains stable even in the face of failures or concurrent operations.

Serializability in DBMS
In this article, we are going to explain the serializability concept and how this concept
affects the DBMS deeply, we also understand the concept of serializability with some
examples, and we will finally conclude this topic with an example of the importance
of serializability. The DBMS form is the foundation of the most modern applications,
and when we design the form properly, it provides high-performance and relative
storage solutions to our application.
What is a serializable schedule, and what is it used for?
If a non-serial schedule can be transformed into its corresponding serial schedule, it is
said to be serializable. Simply said, a non-serial schedule is referred to as a
serializable schedule if it yields the same results as a serial timetable.
Non-serial Schedule
A schedule where the transactions are overlapping or switching places. As they are
used to carry out actual database operations, multiple transactions are running at once.
It’s possible that these transactions are focusing on the same data set. Therefore, it is
crucial that non-serial schedules can be serialized in order for our database to be
consistent both before and after the transactions are executed.
Example:

Transaction-1 Transaction-2

R(a)

W(a)

R(b)

W(b)

R(b)

R(a)

W(b)

W(a)

We can observe that Transaction-2 begins its execution before Transaction-1 is

finished, and they are both working on the same data, i.e., “a” and “b”,
interchangeably. Where “R”-Read, “W”-Write
Serializability testing
We can utilize the Serialization Graph or Precedence Graph to examine a schedule’s
serializability. A schedule’s full transactions are organized into a Directed Graph,
what a serialization graph is.

Precedence Graph

It can be described as a Graph G(V, E) with vertices V = “V1, V2, V3,…, Vn” and
directed edges E = “E1, E2, E3,…, En”. One of the two operations—READ or
WRITE—performed by a certain transaction is contained in the collection of edges.
Where Ti -> Tj, means Transaction-Ti is either performing read or write before the
transaction-Tj.
Types of Serializability
There are two ways to check whether any non-serial schedule is serializable.

Types of Serializability – Conflict & View

1. Conflict serializability
Conflict serializability refers to a subset of serializability that focuses on maintaining
the consistency of a database while ensuring that identical data items are executed in
an order. In a DBMS each transaction has a value and all the transactions, in the
database rely on this uniqueness. This uniqueness ensures that no two operations with
the conflict value can occur simultaneously.
For example lets consider an order table and a customer table as two instances. Each
order is associated with one customer even though a single client may place orders.
However there are restrictions for achieving conflict serializability in the database.
Here are a few of them.
1. Different transactions should be used for the two procedures.
2. The identical data item should be present in both transactions.
3. Between the two operations, there should be at least one write operation.
Example
Three transactions—t1, t2, and t3—are active on a schedule “S” at once. Let’s create a
graph of precedence.
Transaction – 1 (t1) Transaction – 2 (t2) Transaction – 3 (t3)

R(a)

R(b)

R(b)
Transaction – 1 (t1) Transaction – 2 (t2) Transaction – 3 (t3)

W(b)

W(a)

W(a)

R(a)

W(a)

It is a conflict serializable schedule as well as a serial schedule because the graph (a

DAG) has no loops. We can also determine the order of transactions because it is a
serial schedule.

DAG of transactions

As there is no incoming edge on Transaction 1, Transaction 1 will be executed first.

T3 will run second because it only depends on T1. Due to its dependence on both T1
and T3, t2 will finally be executed.
Therefore, the serial schedule’s equivalent order is: t1 –> t3 –> t2
Note: A schedule is unquestionably consistent if it is conflicting serializable. A non-
conflicting serializable schedule, on the other hand, might or might not be serial. We
employ the idea of View Serializability to further examine its serial behavior.
2. View Serializability
View serializability is a kind of operation in a serializable in which each transaction
should provide some results, and these outcomes are the output of properly
sequentially executing the data item. The view serializability, in contrast to conflict
serialized, is concerned with avoiding database inconsistency. The view serializability
feature of DBMS enables users to see databases in contradictory ways.
To further understand view serializability in DBMS, we need to understand the
schedules S1 and S2. The two transactions T1 and T2 should be used to establish
these two schedules. Each schedule must follow the three transactions in order to
retain the equivalent of the transaction. These three circumstances are listed below.
1. The first prerequisite is that the same kind of transaction appears on every
schedule. This requirement means that the same kind of group of transactions
cannot appear on both schedules S1 and S2. The schedules are not equal to one
another if one schedule commits a transaction but it does not match the transaction
of the other schedule.
2. The second requirement is that different read or write operations should not be
used in either schedule. On the other hand, we say that two schedules are not
similar if schedule S1 has two write operations whereas schedule S2 only has one.
The number of the write operation must be the same in both schedules, however
there is no issue if the number of the read operation is different.
3. The second to last requirement is that there should not be a conflict between either
timetable. execution order for a single data item. Assume, for instance, that
schedule S1’s transaction is T1, and schedule S2’s transaction is T2. The data item
A is written by both the transaction T1 and the transaction T2. The schedules are
not equal in this instance. However, we referred to the schedule as equivalent to
one another if it had the same number of all write operations in the data item.
What is view equivalency?
Schedules (S1 and S2) must satisfy these two requirements in order to be viewed as
equivalent:
1. The same piece of data must be read for the first time. For instance, if transaction
t1 is reading “A” from the database in schedule S1, then t1 must also read A in
schedule S2.
2. The same piece of data must be used for the final write. As an illustration, if
transaction t1 updated A last in S1, it should also conduct final write in S2.
3. The middle sequence need to follow suit. As an illustration, if in S1 t1 is reading
A, and t2 updates A, then in S2 t1 should read A, and t2 should update A.
View Serializability refers to the process of determining whether a schedule’s views
are equivalent.
Example
We have a schedule “S” with two concurrently running transactions, “t1” and “t2.”
Schedule – S:
Transaction-1 (t1) Transaction-2 (t2)

R(a)
Transaction-1 (t1) Transaction-2 (t2)

W(a)

R(a)

W(a)

R(b)

W(b)

R(b)

W(b)

By switching between both transactions’ mid-read-write operations, let’s create its

view equivalent schedule (S’).
Schedule – S’:
Transaction-1 (t1) Transaction-2 (t2)

R(a)

W(a)

R(b)

W(b)

R(a)

W(a)

R(b)

W(b)
 It is a view serializable schedule since a view similar schedule is conceivable.
Note: A conflict serializable schedule is always viewed as
serializable, but vice versa is not always true.

Advantages of Serializability
1. Execution is predictable: In serializable, the DBMS’s threads are all performed
simultaneously. The DBMS doesn’t include any such surprises. In DBMS, no data
loss or corruption occurs and all variables are updated as intended.
2. DBMS executes each thread independently, making it much simpler to understand
and troubleshoot each database thread. This can greatly simplify the debugging
process. The concurrent process is therefore not a concern for us.
3. Lower Costs: The cost of the hardware required for the efficient operation of the
database can be decreased with the aid of the serializable property. It may also
lower the price of developing the software.
4. Increased Performance: Since serializable executions provide developers the
opportunity to optimize their code for performance, they occasionally outperform
non-serializable equivalents.
For a DBMS transaction to be regarded as serializable, it must adhere to the ACID
properties. In DBMS, serializability comes in a variety of forms, each having
advantages and disadvantages of its own. Most of the time, choosing the best sort of
serializability involves making a choice between performance and correctness.
Making the incorrect choice for serializability might result in database issues that are
challenging to track down and resolve. You should now have a better knowledge of
how serializability in DBMS functions and the different types that are available thanks
to this guide.
Recoverability in DBMS

Recoverability is a property of database systems that ensures that, in the event of a
failure or error, the system can recover the database to a consistent state.
Recoverability guarantees that all committed transactions are durable and that their
effects are permanently stored in the database, while the effects of uncommitted
transactions are undone to maintain data consistency.
The recoverability property is enforced through the use of transaction logs, which
record all changes made to the database during transaction processing. When a failure
occurs, the system uses the log to recover the database to a consistent state, which
involves either undoing the effects of uncommitted transactions or redoing the effects
of committed transactions.
There are several levels of recoverability that can be supported by a database system:
No-undo logging: This level of recoverability only guarantees that committed
transactions are durable, but does not provide the ability to undo the effects of
uncommitted transactions.
Undo logging: This level of recoverability provides the ability to undo the effects of
uncommitted transactions but may result in the loss of updates made by committed
transactions that occur after the failed transaction.
Redo logging: This level of recoverability provides the ability to redo the effects of
committed transactions, ensuring that all committed updates are durable and can be
recovered in the event of failure.
Undo-redo logging: This level of recoverability provides both undo and redo
capabilities, ensuring that the system can recover to a consistent state regardless of
whether a transaction has been committed or not.
In addition to these levels of recoverability, database systems may also use techniques
such as checkpointing and shadow paging to improve recovery performance and
reduce the overhead associated with logging.
Overall, recoverability is a crucial property of database systems, as it ensures that data
is consistent and durable even in the event of failures or errors. It is important for
database administrators to understand the level of recoverability provided by their
system and to configure it appropriately to meet their application’s requirements.
Prerequisite:
 Introduction to Concurrency Control
 Types of Schedules
As discussed, a transaction may not execute completely due to hardware failure,
system crash or software issues. In that case, we have to roll back the failed
transaction. But some other transactions may also have used values produced by the
failed transaction. So we have to roll back those transactions as well.
Recoverable Schedules:
 Schedules in which transactions commit only after all transactions whose changes
they read commit are called recoverable schedules. In other words, if some
transaction Tj is reading value updated or written by some other transaction T i, then
the commit of Tj must occur after the commit of Ti.
Example 1:
S1: R1(x), W1(x), R2(x), R1(y), R2(y),
W2(x), W1(y), C1, C2;
Given schedule follows order of Ti->Tj => C1->C2. Transaction T1 is executed
before T2 hence there is no chances of conflict occur. R1(x) appears before W1(x)
and transaction T1 is committed before T2 i.e. completion of first transaction
performed first update on data item x, hence given schedule is recoverable.
Example 2: Consider the following schedule involving two transactions T 1 and T2.
T1 T2

R(A)

W(A)

W(A)

R(A)

commit

commit

This is a recoverable schedule since T 1 commits before T2, that makes the value read
by T2 correct.
Irrecoverable Schedule: The table below shows a schedule with two transactions, T1
reads and writes A and that value is read and written by T2. T2 commits. But later on,
T1 fails. So we have to rollback T1. Since T2 has read the value written by T1, it
should also be rollbacked. But we have already committed that. So this schedule is
irrecoverable schedule. When Tj is reading the value updated by Ti and Tj is
committed before committing of Ti, the schedule will be irrecoverable.
Recoverable with Cascading Rollback: The table below shows a schedule with two
transactions, T1 reads and writes A and that value is read and written by T2. But later
on, T1 fails. So we have to rollback T1. Since T2 has read the value written by T1, it
should also be rollbacked. As it has not committed, we can rollback T2 as well. So it
is recoverable with cascading rollback. Therefore, if Tj is reading value updated by Ti
and commit of Tj is delayed till commit of Ti, the schedule is called recoverable with
cascading rollback.

Cascadeless Recoverable Rollback: The table below shows a schedule with two
transactions, T1 reads and writes A and commits and that value is read by T2. But if
T1 fails before commit, no other transaction has read its value, so there is no need to
rollback other transaction. So this is a Cascadeless recoverable schedule. So, if Tj
reads value updated by Ti only after Ti is committed, the schedule will be cascadeless
recoverable.

Question: Which of the following scenarios may lead to an irrecoverable error in a

database system?
1. A transaction writes a data item after it is read by an uncommitted transaction.
2. A transaction reads a data item after it is read by an uncommitted transaction.
3. A transaction reads a data item after it is written by a committed transaction.
 4. A transaction reads a data item after it is written by an uncommitted transaction.
Answer: See the example discussed in Table 1, a transaction is reading a data item
after it is written by an uncommitted transaction, the schedule will be irrecoverable.

The capabilities of recoverability in a DBMS encompass:

Atomicity: Transactions in a DBMS are designed to be atomic, which means that they
either entire absolutely or are rolled back to their unique nation in case of a failure.
This guarantees that the database is usually in a consistent nation.
Durability: Once a transaction is dedicated, its changes are permanently stored to the
database, even in the occasion of a failure. This ensures that the database may be
restored to its closing consistent kingdom after a failure.
Logging: A DBMS keeps a log of all transactions to make sure recoverability. The
log consists of data about all adjustments made to the database, as well as the
transactions that made those changes. In the event of a failure, the log may be used to
repair the database to a regular state.
Checkpointing: A checkpoint is a point in time in which the DBMS records the
country of the database and logs it. This allows lessen the quantity of time required for
recovery in case of a failure, as handiest the transactions since the last checkpoint
need to be rolled back or replayed.
Recovery manager: A restoration supervisor is a part of a DBMS that is accountable
for restoring the database to a constant state after a failure. The healing supervisor
uses the log and checkpoints to determine which transactions want to be rolled
returned or replayed to repair the database.
Media recuperation: Media recovery refers back to the capability of a DBMS to
recover from a failure that affects the garage media, such as a hard disk crash. This
includes restoring the database from a backup and making use of the log to deliver it
up to date.
Deadlock in DBMS

In database management systems (DBMS) a deadlock occurs when two or more
transactions are unable to the proceed because each transaction is waiting for the other
to the release locks on resources. This situation creates a cycle of the dependencies
where no transaction can continue leading to the standstill in the system. The
Deadlocks can severely impact the performance and reliability of a DBMS making it
crucial to the understand and manage them effectively.
What is Deadlock?
The Deadlock is a condition in a multi-user database environment where transactions
are unable to the complete because they are each waiting for the resources held by
other transactions. This results in a cycle of the dependencies where no transaction
can proceed.
Characteristics of Deadlock
 Mutual Exclusion: Only one transaction can hold a particular resource at a time.
 Hold and Wait: The Transactions holding resources may request additional
resources held by others.
 No Preemption: The Resources cannot be forcibly taken from the transaction
holding them.
 Circular Wait: A cycle of transactions exists where each transaction is waiting for
the resource held by the next transaction in the cycle.
In a database management system (DBMS), a deadlock occurs when two or more
transactions are waiting for each other to release resources, such as locks on database
objects, that they need to complete their operations. As a result, none of the
transactions can proceed, leading to a situation where they are stuck or “deadlocked.”
Deadlocks can happen in multi-user environments when two or more transactions are
running concurrently and try to access the same data in a different order. When this
happens, one transaction may hold a lock on a resource that another transaction needs,
while the second transaction may hold a lock on a resource that the first transaction
needs. Both transactions are then blocked, waiting for the other to release the resource
they need.
DBMSs often use various techniques to detect and resolve deadlocks automatically.
These techniques include timeout mechanisms, where a transaction is forced to release
its locks after a certain period of time, and deadlock detection algorithms, which
periodically scan the transaction log for deadlock cycles and then choose a transaction
to abort to resolve the deadlock.
It is also possible to prevent deadlocks by careful design of transactions, such as
always acquiring locks in the same order or releasing locks as soon as possible. Proper
design of the database schema and application can also help to minimize the
likelihood of deadlocks.
In a database, a deadlock is an unwanted situation in which two or more transactions
are waiting indefinitely for one another to give up locks. Deadlock is said to be one of
the most feared complications in DBMS as it brings the whole system to a Halt.
Example – let us understand the concept of deadlock suppose, Transaction T1 holds a
lock on some rows in the Students table and needs to update some rows in the Grades
table. Simultaneously, Transaction T2 holds locks on those very rows (Which T1
needs to update) in the Grades table but needs to update the rows in the Student
table held by Transaction T1.
Now, the main problem arises. Transaction T1 will wait for transaction T2 to give up
the lock, and similarly, transaction T2 will wait for transaction T1 to give up the lock.
As a consequence, All activity comes to a halt and remains at a standstill forever
unless the DBMS detects the deadlock and aborts one of the transactions.
Deadlock in DBMS

What is Deadlock Avoidance?

When a database is stuck in a deadlock, It is always better to avoid the deadlock rather
than restarting or aborting the database. The deadlock avoidance method is suitable
for smaller databases whereas the deadlock prevention method is suitable for larger
databases.
One method of avoiding deadlock is using application-consistent logic. In the above-
given example, Transactions that access Students and Grades should always access
the tables in the same order. In this way, in the scenario described above, Transaction
T1 simply waits for transaction T2 to release the lock on Grades before it begins.
When transaction T2 releases the lock, Transaction T1 can proceed freely.
Another method for avoiding deadlock is to apply both the row-level locking
mechanism and the READ COMMITTED isolation level. However, It does not
guarantee to remove deadlocks completely.
What is Deadlock Detection?
When a transaction waits indefinitely to obtain a lock, The database management
system should detect whether the transaction is involved in a deadlock or not.
Wait-for-graph is one of the methods for detecting the deadlock situation. This
method is suitable for smaller databases. In this method, a graph is drawn based on the
transaction and its lock on the resource. If the graph created has a closed loop or a
cycle, then there is a deadlock. For the above-mentioned scenario, the Wait-For graph
is drawn below:
What is Deadlock Prevention?
For a large database, the deadlock prevention method is suitable. A deadlock can be
prevented if the resources are allocated in such a way that a deadlock never occurs.
The DBMS analyzes the operations whether they can create a deadlock situation or
not, If they do, that transaction is never allowed to be executed.
Deadlock prevention mechanism proposes two schemes:
 Wait-Die Scheme: In this scheme, If a transaction requests a resource that is
locked by another transaction, then the DBMS simply checks the timestamp of
both transactions and allows the older transaction to wait until the resource is
available for execution.
Suppose, there are two transactions T1 and T2, and Let the timestamp of any
transaction T be TS (T). Now, If there is a lock on T2 by some other transaction
and T1 is requesting resources held by T2, then DBMS performs the following
actions:
Checks if TS (T1) < TS (T2) – if T1 is the older transaction and T2 has held some
resource, then it allows T1 to wait until resource is available for execution. That
means if a younger transaction has locked some resource and an older transaction
is waiting for it, then an older transaction is allowed to wait for it till it is available.
If T1 is an older transaction and has held some resource with it and if T2 is waiting
for it, then T2 is killed and restarted later with random delay but with the same
timestamp. i.e. if the older transaction has held some resource and the younger
transaction waits for the resource, then the younger transaction is killed and
restarted with a very minute delay with the same timestamp.
This scheme allows the older transaction to wait but kills the younger one.

 Wound Wait Scheme: In this scheme, if an older transaction requests for a

resource held by a younger transaction, then an older transaction forces a younger
transaction to kill the transaction and release the resource. The younger transaction
 is restarted with a minute delay but with the same timestamp. If the younger
transaction is requesting a resource that is held by an older one, then the younger
transaction is asked to wait till the older one releases it.
The following table lists the differences between Wait – Die and Wound -Wait
scheme prevention schemes:
Wait – Die Wound -Wait

It is based on a non-preemptive technique. It is based on a preemptive technique.

In this, older transactions must wait for the In this, older transactions never wait for
younger one to release its data items. younger transactions.

The number of aborts and rollbacks is higher in In this, the number of aborts and
these techniques. rollback is lesser.

Applications
1. Delayed Transactions: Deadlocks can cause transactions to be delayed, as the
resources they need are being held by other transactions. This can lead to slower
response times and longer wait times for users.
2. Lost Transactions: In some cases, deadlocks can cause transactions to be lost or
aborted, which can result in data inconsistencies or other issues.
3. Reduced Concurrency: Deadlocks can reduce the level of concurrency in the
system, as transactions are blocked waiting for resources to become available. This
can lead to slower transaction processing and reduced overall throughput.
4. Increased Resource Usage: Deadlocks can result in increased resource usage, as
transactions that are blocked waiting for resources to become available continue to
consume system resources. This can lead to performance degradation and
increased resource contention.
5. Reduced User Satisfaction: Deadlocks can lead to a perception of poor system
performance and can reduce user satisfaction with the application. This can have a
negative impact on user adoption and retention.
Features of Deadlock in a DBMS
1. Mutual Exclusion: Each resource can be held by only one transaction at a time,
and other transactions must wait for it to be released.
2. Hold and Wait: Transactions can request resources while holding on to resources
already allocated to them.
3. No Preemption: Resources cannot be taken away from a transaction forcibly, and
the transaction must release them voluntarily.
4. Circular Wait: Transactions are waiting for resources in a circular chain, where
each transaction is waiting for a resource held by the next transaction in the chain.
5. Indefinite Blocking: Transactions are blocked indefinitely, waiting for resources
to become available, and no transaction can proceed.
6. System Stagnation: Deadlock leads to system stagnation, where no transaction
can proceed, and the system is unable to make any progress.
7. Inconsistent Data: Deadlock can lead to inconsistent data if transactions are
unable to complete and leave the database in an intermediate state.
8. Difficult to Detect and Resolve: Deadlock can be difficult to detect and resolve,
as it may involve multiple transactions, resources, and dependencies.
Disadvantages
1. System downtime: Deadlock can cause system downtime, which can result in loss
of productivity and revenue for businesses that rely on the DBMS.
2. Resource waste: When transactions are waiting for resources, these resources are
not being used, leading to wasted resources and decreased system efficiency.
3. Reduced concurrency: Deadlock can lead to a decrease in system concurrency,
which can result in slower transaction processing and reduced throughput.
4. Complex resolution: Resolving deadlock can be a complex and time-consuming
process, requiring system administrators to intervene and manually resolve the
deadlock.
5. Increased system overhead: The mechanisms used to detect and resolve
deadlock, such as timeouts and rollbacks, can increase system overhead, leading to
decreased performance.