3. Transaction Management
• A transaction is a logical unit of work that contains one or
more SQL statements. A transaction is an atomic unit.
• A transaction begins with the first executable SQL statement.
A transaction ends when it is committed or rolled back,
either explicitly with a COMMIT or ROLLBACK statement or
implicitly when a DDL statement is issued.
• For example :
Lets consider a banking database. When a bank customer
transfers money from a savings account to a checking
account, the transaction can consist of three separate
5. Transaction States
There are the following six states in which a transaction may exist:
A) Active: The initial state when the transaction has just started execution.
B) Partially Committed: At any given point of time if the transaction is executing properly,
then it is going towards it COMMIT POINT. The values generated during the execution
are all stored in volatile storage.
C) Failed: If the transaction fails for some reason. The temporary values are no
longer required, and the transaction is set to ROLLBACK. It means that any change made
to the database by this transaction up to the point of the failure must be undone. If the failed
transaction has withdrawn Rs. 100/- from account A, then the ROLLBACK operation should
add Rs 100/- to account A.
D) Aborted: When the ROLLBACK operation is over, the database reaches the BFIM. The
transaction is now said to have been aborted.
6. Transaction States Continue..
E) Committed: If no failure occurs then the transaction reaches the COMMIT POINT. All
the temporary values are written to the stable storage and the transaction is said to have
F) Terminated: Either committed or aborted, the transaction finally reaches this state.
7. Properties of Transaction
A Transaction has four properties, taking the initial letters of these
four properties we collectively call them the ACID Properties.
1. Atomicity: This means that either all of the instructions within
the transaction will be reflected in the database, or none of
them will be reflected.
for example, we have two accounts A and B, each containing
Rs 1000/-. We now start a transaction to deposit Rs 100/- from
account A to Account B.
A = A – 100;
B = B + 100;
8. Properties of Transaction
2. Consistency: If we execute a particular transaction in isolation or
together with other transaction, (i.e. presumably in a multi-
programming environment), the transaction will yield the
same expected result.
• To give better performance, every database management
system supports the execution of multiple transactions at the
same time, using CPU Time Sharing. Concurrently executing
transactions may have to deal with the problem of sharable
resources, i.e. resources that multiple transactions are trying to
read/write at the same time.
• For example . A transaction which deposits Rs 100/- to account
A must deposit the same amount whether it is acting alone or in
conjunction with another transaction that may be trying to
deposit or withdraw some amount at the same time.
9. Properties of Transaction
3. Isolation: In case multiple transactions are executing
concurrently and trying to access a sharable resource at the
same time, the system should create an ordering in their
execution so that they should not create any anomaly in the
value stored at the sharable resource.
4. Durability: It states that once a transaction has been complete
the changes it has made should be permanent.
• As we have seen in the explanation of the Atomicity property,
the transaction, if completes successfully, is committed. Once
the COMMIT is done, the changes which the transaction has
made to the database are immediately written into permanent
storage. So, after the transaction has been committed
successfully, there is no question of any loss of information even
if the power fails. Committing a transaction guarantees that the
AFIM has been reached.
Serializability is a concept that helps to identify
which non-serial schedules are correct and will
maintain the consistency of the database.
When multiple transactions run concurrently, then it
may give rise to inconsistency of the database.
• Serializable Schedules-
If a given schedule of ‘n’ transactions is found to
be equivalent to some serial schedule of ‘n’
transactions, then it is called as a serializable
11. Serializability Continue..
1. Properties of Serializable Schedules-
Serializable schedules behave exactly same as serial schedules. So, they are
2. Difference between Serial Schedules and Serializable Schedules-
The only difference between serial schedules and serializable schedules is
In serial schedules, only one transaction is allowed to execute at a
time i.e. no concurrency is allowed.
Whereas in serializable schedules, multiple transactions can execute
simultaneously i.e. concurrency is allowed.
13. Conflict Serializability
If a given schedule can be converted into a serial schedule
by swapping its non-conflicting operations, then it is
called as a conflict serializable schedule.
• What are conflicting operations?
Two operations are called as conflicting operations if all
the following conditions hold true for them-
– Both the operations belong to different
– Both the operations are on same data item
– At least one of the two operations is a write
15. Checking of conflict serializable schedule
Find and list all the conflicting operations.
Start creating a precedence graph by drawing one node for each transaction.
Draw an edge for each conflict pair such that if Xi (V) and Yj (V) forms a conflict
pair then draw an edge from Ti to Tj which ensures that Ti gets executed before Tj.
Check if there is any cycle formed in the graph. If there is no cycle found, then
the schedule is conflict serializable otherwise not.
16. View Serializability-
If a given schedule is found to be view equivalent to some serial
schedule, then it is called as a view serializable schedule.
What are view equivalent schedules?
• Consider two schedules S1 and S2 each consisting of two
transactions T1 and T2. Schedules S1 and S2 are called view
equivalent if the following three conditions hold true for
If transaction Ti reads a data item X from the database initially in
schedule S1, then in schedule S2 also, Ti must perform the initial
read of the data item X from the database.
The same has to be true for all the data items.
17. View Serializability-
“Initial reads must be same for all data items”.
• If transaction Ti reads a data item that has been updated by
the transaction Tj in schedule S1, then in schedule S2 also,
transaction Ti must read the same data item that has been
updated by transaction Tj.
“Write-read sequence must be same.”.
18. View Serializability-
• If data item X has been updated at last by transaction Ti in schedule
S1, then in schedule S2 also, the data item X must be updated at last
by transaction Ti
• The same has to be true for all the data items.
“Final writers must be same for all data items”.
How to check whether a given schedule is view serializable or not?
Check whether the given schedule is conflict serializable or not.
• If the given schedule is conflict serializable, then it is surely view
serializable. Stop and report your answer.
If the given schedule is not conflict
serializable, then it may or may not be
view serializable. Go and check using
All conflict serializable schedules are view serializable but all view
serializable schedules may or may not be conflict serializable.
Check if there exists any blind write operation (writing without
reading a value is known as a blind write).
• If there does not exist any blind write, then the schedule is
surely not view serializable. Stop and report your answer.
• If there exists any blind write, then the schedule may or may
not be view serializable. Go and check using other methods.
No blind write means not a view serializable schedule.
• In this method, try finding a view equivalent serial schedule.
• By using the three conditions mentioned above, write all the
dependencies and then draw a graph using those
dependencies. If there exists no cycle, then the schedule is
view serializable otherwise not.
• 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 with an
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
23. 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. Deadlock avoidance method is suitable for smaller
database whereas deadlock prevention method is suitable for
• 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
• Another method for avoiding deadlock is to apply both row
level locking mechanism and READ COMMITTED isolation
level. However, It does not guarantee to remove deadlocks
24. Deadlock Detection
• 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
database. In this method a graph is drawn based on the
transaction and their lock on the resource. If the graph
created has a closed loop or a cycle, then there is a deadlock.
• For Example: 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.
26. 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.
• There are deadlock prevention schemes that use
timestamp ordering mechanism of transactions in
order to predetermine a deadlock situation.
27. Deadlock Prevention
1. 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
• 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
Note: 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.
28. Deadlock Prevention
2. 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
• If TS(Ti) > TS(tj) − that is Ti is younger than Tj − then Tidies. Ti is
restarted later with a random delay but with the same timestamp.
Note: This scheme allows the older transaction to wait but kills the