Transaction Management,

Concurrency Control and

Deadlocks
Dr. V. V. Subrahmanyam
Associate Professor,
SOCIS, IGNOU
 Transaction

• A transaction can be defined as a group of

tasks. A single task is the minimum
processing unit which cannot be divided
further.
 States of a Transaction
• Active − In this state, the transaction is
being executed. This is the initial state
of every transaction.
• Partially Committed − When a
transaction executes its final
operation, it is said to be in a partially
committed state.
• Failed − A transaction is said to be in a
failed state if any of the checks made by
the database recovery system fails. A failed
transaction can no longer proceed further.
• Aborted − If any of the checks fails and the
transaction has reached a failed state, then the
recovery manager rolls back all its write
operations on the database to bring the database
back to its original state where it was prior to the
execution of the transaction.
• Transactions in this state are called aborted. The
database recovery module can select one of the
two operations after a transaction aborts −
– Re-start the transaction
– Kill the transaction
• Committed − If a transaction executes all its
operations successfully, it is said to be
committed. All its effects are now
permanently established on the database
system.
States of a Transaction
 ACID Properties
• A transaction in a database system must
maintain Atomicity, Consistency, Isolation,
and Durability − commonly known as ACID
properties − in order to ensure accuracy,
completeness, and data integrity.
 Atomicity
• This property states that a transaction must
be treated as an atomic unit, that is, either all
of its operations are executed or none.
• There must be no state in a database where a
transaction is left partially completed.
• States should be defined either before the
execution of the transaction or after the
execution/abortion/failure of the transaction.
 Consistency
• The database must remain in a consistent
state after any transaction. No transaction
should have any adverse effect on the data
residing in the database. If the database was
in a consistent state before the execution of a
transaction, it must remain consistent after
the execution of the transaction as well.
 Isolation
• In a database system where more than one
transaction are being executed simultaneously
and in parallel, the property of isolation states
that all the transactions will be carried out
and executed as if it is the only transaction in
the system.
• No transaction will affect the existence of any
other transaction.
 Durability
• The database should be durable enough to hold
all its latest updates even if the system fails or
restarts.
• If a transaction updates data in a DB and
commits, then the DB will hold the modified data.
• If a transaction commits but the system fails
before the data could be written on to the disk,
then that data will be updated once the system
springs back into action.
 Schedule

• A chronological execution sequence of a

transaction is called a schedule. A
schedule can have many transactions in it,
each comprising of a number of
instructions/tasks.
 Serial Schedule
• It is a schedule in which transactions are
aligned in such a way that one transaction is
executed first.
• When the first transaction completes its
cycle, then the next transaction is executed.
• Transactions are ordered one after the other.
This type of schedule is called a serial
schedule, as transactions are executed in a
serial manner.
• In a multi-transaction environment, the
execution sequence of an instruction in a
transaction cannot be changed, but two
transactions can have their instructions
executed in a random fashion.
• This execution does no harm if two
transactions are mutually independent and
working on different segments of data.
• But in case these two transactions are
working on the same data, then the
results may vary. This ever-varying result
may bring the database to an
inconsistent state.
• To resolve this problem, we allow
parallel execution of a transaction
schedule, if its transactions are either
serializable or have some equivalence
relation among them.
 Concurrency Control
• In a multiprogramming environment where
multiple transactions can be executed
simultaneously, it is highly important to
control the concurrency of transactions. We
have concurrency control protocols to ensure
atomicity, isolation, and serializability of
concurrent transactions.
 Categories of Protocols

• Concurrency control protocols can be

broadly divided into two categories −
– Lock based protocols
– Time stamp based protocols
 Lock-Based Protocols
• Database systems equipped with lock-based
protocols use a mechanism by which any
transaction cannot read or write data until it
acquires an appropriate lock on it. Locks are of
two kinds −
– Binary Locks
– Shared / Exclusive Locks
 Binary Locks

• A lock on a data item can be in

two states; it is either locked or
unlocked.
 Shared / Exclusive Locks
• This type of locking mechanism
differentiates the locks based on their
uses.
• If a lock is acquired on a data item to
perform a write operation, it is an
exclusive lock.
• Read locks are shared because no data
value is being changed.
 Timestamp-based Protocols

• The most commonly used concurrency

protocol is the timestamp based protocol.
• This protocol uses either system time or
logical counter as a timestamp
• Lock-based protocols manage the order
between the conflicting pairs among
transactions at the time of execution,
whereas timestamp-based protocols
start working as soon as a transaction is
created.
• Every transaction has a timestamp
associated with it, and the ordering is
determined by the age of the
transaction.
• In addition, every data item is given
the latest read and write-timestamp.
• This lets the system know when the
last ‘read and write’ operation was
performed on the data item.
 Deadlock

• Deadlock is a process indefinitely waits

for a resource that is held by another
process.
 Example
• A set of transactions {T0, T1, T2, ...,Tn}.
• T0 needs a resource X to complete its
task.
• Resource X is held by T1
• 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.
• This is an unwanted state for any system
• The transactions involved in the deadlock
are either rolled back or restarted.
 Deadlock Prevention
• To prevent any deadlock situation in the
system, the DBMS aggressively inspects all
the operations, where transactions are about
to execute.
• The DBMS inspects the operations and
analyzes if they can create a deadlock
situation.
• If it finds that a deadlock situation might
occur, then that transaction is never allowed
to be executed.
Deadlock Prevention Schemes

• Wait-Die Scheme
• Wound-Wait Scheme
 Deadlock Avoidance
• Aborting a transaction is not always a
practical approach.
• Instead, deadlock avoidance mechanisms
can be used to detect any deadlock situation
in advance.
• Methods like "wait-for graph" are available
but they are suitable for only those systems
where transactions are lightweight having
fewer instances of resource.
• In a bulky system, deadlock prevention
techniques may work well.