Database Management System Unit 4

Unit 4 Transaction Processing

Transaction
A transaction is a unit of program execution that accesses and possibly updates various data items. Usually, a
transaction is initiated by a user program written in a high-level data manipulation language (typically SQL), or
programming language (e.g., C++ or Java), with embedded database accesses in JDBC or ODBC. A transaction
is delimited by statements (or function calls) of the form begin transaction and end transaction. The transaction
consists of all operations executed between the begin transaction and end transaction.
Examples of such systems include systems for reservations, banking, credit card processing, stock markets,
supermarket checkout, and other similar systems. They require high availability and fast response time for
hundreds of concurrent users. A simple example of a transaction will be dealing with the bank accounts of two
users, let say Karlos and Ray. A simple transaction of moving an amount of 5000 from Karlos to Ray engages
many low-level jobs. As the amount of Rs. 5000 gets transferred from the Karlos's account to Ray's account, a
series of tasks gets performed in the background of the screen.
Example of a small transaction : decrease Karlos's bank account from 5000:
Open_Acc (Karlos)
OldBal = [Link]
NewBal = OldBal - 5000
CloseAccount(Karlos)
For adding amount 5000 in Ray's account, the same sort of tasks needs to be done:
OpenAccount(Ray)
Old_Bal = [Link]
NewBal = OldBal + 5000
CloseAccount(B)

Transaction States
These are different types of Transaction States:
Active State – When the instructions of the transaction are running then the transaction is in active state. If all
the ‘read and write’ operations are performed without any error then it goes to the “partially committed state”; if
any instruction fails, it goes to the “failed state”.
Partially Committed – In the partially committed state, a transaction executes its final operation, but the data is
still not saved to the database.
Failed State –When any instruction of the transaction fails, it goes to the “failed state” or if failure occurs in
making a permanent change of data on Database.
Aborted State –After having any type of failure, the transaction goes from “failed state” to “aborted state” and
since in previous states, the changes are only made to local buffer or main memory and hence these changes
Prepared By- Charu Kavadia Page 1
 Database Management System Unit 4

are deleted or rolled-back.

Committed State –It is the state when the changes are made permanent on the Data Base and the transaction is
complete and therefore terminated in the “terminated state”.
Terminated State –If there isn’t any roll-back or the transaction comes from the “committed state”, then the
system is consistent and ready for new transaction and the old transaction is terminated. A transaction is said to
have terminated if it has either committed or aborted.
A transaction enters the failed state after the system determines that the transaction can no longer proceed with
its normal execution (e.g., because of hardware or logical errors). Such a transaction must be rolled back. Then,
it enters the aborted state. At this point, the system has two options:
 It can restart the transaction, but only if the transaction was aborted as a result of some hardware or software
error that was not created through the internal logic of the transaction. A restarted transaction is considered
to be a new transaction.
 It can kill the transaction. It usually does so because of some internal logical error that can be corrected only
by rewriting the application program, or because the input was bad, or because the desired data were not
found in the database.

Transaction Properties
Transactions access data using two operations:
 read(X), which transfers the data item X from the database to a variable, also called X, in a buffer in
main memory belonging to the transaction that executed the read operation.
 write(X), which transfers the value in the variable X in the main-memory buffer of the transaction that
executed the write to the data item X in the database.
Example- A simple bank application consisting of several accounts and a set of transactions that access and
update those accounts. Let Ti be a transaction that transfers $50 from account A to account B. This transaction
can be defined as:
Prepared By- Charu Kavadia Page 2
 Database Management System Unit 4

Transaction Properties (ACID Properties)

1) Atomicity: This property ensures that either all the operations of a transaction reflect in database or none.
Suppose that, just before the execution of transaction Ti, the values of accounts A and B are $1000 and $2000,
respectively. Now suppose that, during the execution of transaction Ti, a failure occurs that prevents Ti from
completing its execution successfully. Further, suppose that the failure happened after the write (A) operation
but before the write(B) operation. In this case, the values of accounts A and B reflected in the database are $950
and $2000. The system destroyed $50 as a result of this failure. In particular, we note that the sum A + B is no
longer preserved.
Thus, because of the failure, the state of the system no longer reflects a real state of the world that the database
is supposed to capture. We term such a state an inconsistent state. We must ensure that such inconsistencies are
not visible in a database system. Note, however, that the system must at some point be in an inconsistent state.
Even if transaction Ti is executed to completion, there exists a point at which the value of account A is $950
and the value of account B is $2000, which is clearly an inconsistent state. This state, however, is eventually
replaced by the consistent state where the value of account A is $950, and the value of account B is $2050.
Thus, if the transaction never started or was guaranteed to complete, such an inconsistent state would not be
visible except during the execution of the transaction. That is the reason for the atomicity requirement: If the
atomicity property is present, all actions of the transaction are reflected in the database, or none are.
The basic idea behind ensuring atomicity is this: The database system keeps track (on disk) of the old values of
any data on which a transaction performs a write. This information is written to a file called the log. If the
transaction does not complete its execution, the database system restores the old values from the log to make it
appear as though the transaction never executed.
2) Consistency: The consistency requirement here is that the sum of A and B be unchanged by the execution of
the transaction. Without the consistency requirement, money could be created or destroyed by the transaction! It
can be verified easily that, if the database is consistent before an execution of the transaction, the database the
remains consistent after the execution of the transaction. Ensuring consistency for an individual transaction is
responsibility of the application programmer who codes the transaction.
3) Isolation: For every pair of transactions, one transaction should start execution only when the other finished
execution. Even if the consistency and atomicity properties are ensured for each transaction, if several
transactions are executed concurrently, their operations may interleave in some undesirable way, resulting in an

Prepared By- Charu Kavadia Page 3

 Database Management System Unit 4

inconsistent state.
For example, as we saw earlier, the database is temporarily inconsistent while the transaction to transfer funds
from A to B is executing, with the deducted total written to A and the increased total yet to be written to B. If a
second concurrently running transaction reads A and B at this intermediate point and computes A + B, it will
observe an inconsistent value. Furthermore, if this second transaction then performs updates on A and B based
on the inconsistent values that it read, the database may be left in an inconsistent state even after both
transactions have completed.
A way to avoid the problem of concurrently executing transactions is to execute transactions serially—that is,
one after the other.
4) 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. Once the execution of the transaction completes successfully, and the user who
initiated the transaction has been notified that the transfer of funds has taken place, it must be the case that no
system failure can result in a loss of data corresponding to this transfer of funds. The durability property
guarantees that, once a transaction completes successfully, all the updates that it carried out on the database
persist, even if there is a system failure after the transaction completes execution.
We can guarantee durability by ensuring that either:
1. The updates carried out by the transaction have been written to disk before the transaction completes.
2. Information about the updates carried out by the transaction is written to disk, and such information is
sufficient to enable the database to reconstruct the updates when the database system is restarted after the
failure.

Concurrent Execution
A schedule is a collection of many transactions which is implemented as a unit.
Depending upon how these transactions are arranged in within a schedule, a schedule can be of two types:
Serial: The transactions are executed one after another, in a non-pre-emptive (which cannot be stopped)
manner.
Concurrent: The transactions are executed in a pre-emptive (which can be stopped), time shared method.
In Serial schedule, there is no question of sharing a single data item among many transactions, because not more
than a single transaction is executing at any point of time. However, a serial schedule is inefficient in the sense
that the transactions suffer for having a longer waiting time and response time, as well as low amount of
resource utilization.
In concurrent schedule, CPU time is shared among two or more transactions in order to run them concurrently.
However, this creates the possibility that more than one transaction may need to access a single data item for
read /write purpose and the database could contain inconsistent value if such accesses are not handled properly.

Prepared By- Charu Kavadia Page 4

 Database Management System Unit 4

Example-
Let us consider there are two transactions T1 and T2, whose instruction sets are given as following.
T1 is an example where $100 is transferred from A to B.
T2 is transaction which deposits to account C 10% of the amount in account A.
T1
Read A; A=500
A = A – 100; A=400
Write A;
Read B;
B = B + 100;
Write B;
T2
Read A; A=400
Temp = A * 0.1; Temp=40
Read C;
C = C + Temp; =C+40
Write C;
If we prepare a serial schedule, then either T1 will completely finish before T2 can begin, or T2 will completely
finish before T1 can begin. However, if we want to create a concurrent schedule, then some Context Switching
need to be made, so that some portion of T1 will be executed, then some portion of T2 will be executed and so
on. For example say we have prepared the following concurrent schedule.
T1 T2
Read A; A=500
A = A - 100; A=400
Write A; A=400
Read A; A=400
Temp = A * 0.1; Temp=40
Read C;
C = C + Temp; =C + 40
Write C;
Read B; B=500
B = B + 100; B=600
Write B; B=600
No problem here. We have made some Context Switching in this Schedule, the first one after executing the
third instruction of T1, and after executing the last statement of T2. T1 first deducts Rs 100/- from A and writes

Prepared By- Charu Kavadia Page 5

 Database Management System Unit 4

the value to C. The new value of Rs 400/- into A. T2 reads the value of A, calculates the value of Temp to
be Rs 40/- and adds remaining part of T1 is executed and Rs 100/- is added to B.
It is clear that a proper Context Switching is very important in order to maintain the Consistency and Isolation
properties of the transactions. But let us take another example where a wrong Context Switching can bring
about disaster. Consider the following example involving the same T1 and T2.
T1 T2
Read A; A=500
A = A - 100; A=400
Read A; A=500
Temp = A * 0.1; Temp=50
Read C;
C = C + Temp; C+50
Write C;
Write A; A= 400
Read B; B= 500
B = B + 100; B=600
Write B; B=600
This schedule is wrong, because we have made the switching at the second instruction of T1. The result is very
confusing. If we consider accounts A and B both containing Rs 1000/- each, then the result of this schedule
should have left Rs 400/- in A, Rs 600/- in B and add Rs 50 in C (as C should be increased by 10% of the
amount in A). But in this wrong schedule, the Context Switching is being performed before the new value of Rs
400/- has been updated in A. T2 reads the old value of A, which is still Rs 500/-, and deposits Rs 50/- in C. C
makes an unjust gain of Rs 10/- out of nowhere.

Schedule
A schedule is defined as an execution sequence of transactions. A schedule maintains the order of the operation
in each individual transaction. A schedule is the arrangement of transaction operations. A schedule may contain
a set of transactions. We already know that a transaction is a set of operations. To run transactions concurrently,
we arrange or schedule their operations in an interleaved fashion.
Schedules are divided into following categories-
 Serial Schedule
 Non-serial Schedule
 Serializable Schedule
 Conflict Serializable Schedule
 View Serializable Schedule

Prepared By- Charu Kavadia Page 6

 Database Management System Unit 4

 Non-Serializable Schedule
 Recoverable Schedule
 Cascading Schedule
 Cascadeless Schedule
 Strict Schedule
 Non-Recoverable Schedule

1. Serial Schedules: Schedules in which the transactions are executed non-interleaved, i.e., a serial schedule is
one in which no transaction starts until a running transaction has ended are called serial schedules. i.e., 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.
Example: Consider the following schedules (A and B) each hold two transactions T1 and T2. In Serial schedule
two transactions execute separately. They cannot execute at the same time as given below.

These are serial schedules since the transactions perform serially in the order T1 —> T2 or T2 —> T1.
Prepared By- Charu Kavadia Page 7
 Database Management System Unit 4

Advantage of Serial Schedule

Main benefit of serial schedule is that there is no concurrency problem. Concurrency problem occurs when two
transactions are accessing the same data in such a way that execution of one transaction will affect the other
transaction.
Disadvantage of Serial Schedule
It is time wasting approach because if T1, T2, T3 arrive at same time then T2, T3 has to wait until T1 is
completed.
2. Non-Serial Schedule: This is a type of Scheduling where the operations of multiple transactions are
interleaved. This might lead to a rise in the concurrency problem. The transactions are executed in a non-serial
manner, keeping the end result correct and same as the serial schedule. Unlike the serial schedule where one
transaction must wait for another to complete all its operation, in the non-serial schedule, the other transaction
proceeds without waiting for the previous transaction to complete. This sort of schedule does not provide any
benefit of the concurrent transaction.
Example: Following schedules are non-serial where T1 and T2 are running concurrently.
The operations of T1 and T2 are interleaved.

Advantage of Non- Serial Schedule

Time Saving.
Disadvantage of Non- Serial Schedule
It causes the Concurrency problem and Read write Conflict problem.
Differences between Serial and Non-Serial Schedule

Prepared By- Charu Kavadia Page 8

 Database Management System Unit 4

The Non-Serial Schedule can be divided further into, Serializable and Non-Serializable Schedule.
a) Serializable Schedule: This is used to maintain the consistency of the database. It is mainly used in the Non-
Serial scheduling to verify whether the scheduling will lead to any inconsistency or not. On the other hand, a
serial schedule does not need the serializability because it follows a transaction only when the previous
transaction is complete. The non-serial schedule is said to be in a serializable schedule only when it is
equivalent to the serial schedules, for an n number of transactions. Since concurrency is allowed in this case
thus, multiple transactions can execute concurrently.

Need (Advantages) of Serializability

In the case of a serial schedule, the multiple transactions involved are executed one after the other sequentially
with no overlap. This helps maintain the consistency in the database but limits the scope of concurrency and
often a smaller transaction might end up waiting for a long time due to an execution of a previous longer
transaction. Serial schedule also consumes a lot of CPU resources which gets wasted due to the serial execution.
In the case with a non-serial schedule, the multiple transactions executed are interleaved leading to
inconsistency in the database but at the same time helps overcome the disadvantages of a serial schedule such as
non-concurrent execution and wastage of CPU resources. It increases throughput which is nothing but the
number of transactions completed per unit time and it reduces waiting time.
It’s established that the execution of multiple transactions in a non-serial schedule takes place concurrently. And
because of the multiple combinations involved, the output obtained may be incorrect at times which cannot be
afforded. This is where serializability comes into the picture and help us determine if the output obtained from a
parallelly executed schedule is correct or not.
In other words, Serializability serves as a measure of correctness for the transactions executed concurrently. It
serves a major role in concurrency control that is crucial for the database and is considered to provide maximum
isolation between the multiple transactions involved. The process of Serializability can also help in achieving
the database consistency which otherwise is not possible for a non-serial schedule.

These are of two types of Serializable Schedule:

1. Conflict Serializable: A schedule is called conflict serializable if it can be transformed into a serial schedule
by swapping non-conflicting operations. Two schedules are said to be conflict equivalent if one schedule can be
converted into other schedule after swapping non-conflicting operations.
Conflicting Operations-
Two operations are called as conflicting operations if all the following conditions hold true for them-
 Both the operations belong to different transactions.
 Both the operations are on the same data item.
 At least one of the two operations is a write operation. (If the read instruction is performed first, then it

Prepared By- Charu Kavadia Page 9

 Database Management System Unit 4

reads the old value of the data item and after the reading is over, the new value of the data item is
written. It the write instruction is performed first, then it updates the data item with the new value and
the read instruction reads the newly updated value. If both the transactions are for write operation, then
they are in conflict but can be allowed to take place in any order, because the transaction do not read
the value updated by each other. However, the value that persists in the data item after the schedule is
over is the one written by the instruction that performed the last write. )
Example 1-

Lets swap non-conflicting operations:

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

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

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

We finally got a serial schedule after swapping all the non-conflicting operations so we can say that the given
schedule is Conflict Serializable.
Example 2-

Prepared By- Charu Kavadia Page 10

 Database Management System Unit 4

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.
2. View Serializable: A Schedule is called view serializable if it is view equivalent to a serial schedule (no
overlapping transactions).
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 v/s Initial Read: 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.
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.
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

Prepared By- Charu Kavadia Page 11

 Database Management System Unit 4

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.
Note- all conflict serializable schedules can be view serializable, but all view serializable schedules may or may
not be conflict serializable.

Differences between Conflict Serializability and View Serializability

Prepared By- Charu Kavadia Page 12

 Database Management System Unit 4

Testing for Serializability

Serialization Graph is used to test the Serializability of a schedule.
Assume a schedule S. For S, we construct a graph known as precedence graph. This graph has a pair G = (V, E),
where V consists a set of vertices, and E consists a set of edges. The set of vertices is used to contain all the
transactions participating in the schedule. The set of edges is used to contain all edges Ti ->Tj for which one of
the three conditions holds:
1. Create a node Ti → Tj if Ti executes write (Q) before Tj executes read (Q).
2. Create a node Ti → Tj if Ti executes read (Q) before Tj executes write (Q).
3. Create a node Ti → Tj if Ti executes write (Q) before Tj executes write (Q).

 If a precedence graph contains a single edge Ti → Tj, then all the instructions of Ti are executed before
the first instruction of Tj is executed.
 If a precedence graph for schedule S contains a cycle, then S is non-serializable. If the precedence graph
has no cycle, then S is known as serializable.
Example 1:

Explanation:
Read(A): In T1, no subsequent writes to A, so no new edges
Read(B): In T2, no subsequent writes to B, so no new edges
Read(C): In T3, no subsequent writes to C, so no new edges

Prepared By- Charu Kavadia Page 13

 Database Management System Unit 4

Write(B): B is subsequently read by T3, so add edge T2 → T3

Write(C): C is subsequently read by T1, so add edge T3 → T1
Write(A): A is subsequently read by T2, so add edge T1 → T2
Write(A): In T2, no subsequent reads to A, so no new edges.
Write(C): In T1, no subsequent reads to C, so no new edges.
Write(B): In T3, no subsequent reads to B, so no new edges.
Precedence graph for schedule S1:

The precedence graph for schedule S1 contains a cycle that's why Schedule S1 is non-serializable.
Example 2:

Explanation:
Read(A): In T4,no subsequent writes to A, so no new edges.
Read(C): In T4, no subsequent writes to C, so no new edges.
Write(A): A is subsequently read by T5, so add edge T4 → T5.
Read(B): In T5,no subsequent writes to B, so no new edges.
Write(C): C is subsequently read by T6, so add edge T4 → T6.
Write(B): A is subsequently read by T6, so add edge T5 → T6.
Prepared By- Charu Kavadia Page 14
 Database Management System Unit 4

Write(C): In T6, no subsequent reads to C, so no new edges.

Write(A): In T5, no subsequent reads to A, so no new edges.
Write(B): In T6, no subsequent reads to B, so no new edges.

Precedence graph for schedule S2:

The precedence graph for schedule S2 contains no cycle that's why ScheduleS2 is serializable.

b) Non-Serializable Schedule: A non-serial schedule which is not serializable is called as a non-serializable

schedule. A non-serializable schedule is not guaranteed to produce the the same effect as produced by some
serial schedule on any consistent database.
The non-serializable schedule is divided into two types, Recoverable and Non-Recoverable Schedule.
1. Recoverable Schedule: 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 Ti, then the commit of Tj must occur after the commit of Ti.
If in a schedule,
 A transaction performs a dirty read operation from an uncommitted transaction
 And its commit operation is delayed till the uncommitted transaction either commits or roll backs,
then such a schedule is known as a Recoverable Schedule.
Example – Consider the following schedule involving two transactions T1 and T2.

This is a recoverable schedule since T1 commits before T2,that makes the value read by T2 correct.
Recoverable Schedule is further classified into cascading, cascadeless and strict schedules.
(i) Cascading Schedule- Also called Avoids cascading aborts/rollbacks (ACA). When there is a failure in
one transaction and this leads to the rolling back or aborting other dependent transactions, then such
scheduling is referred to as Cascading rollback or cascading abort.
Example: For example, transaction T1 writes uncommitted x that is read by Transaction [Link]

Prepared By- Charu Kavadia Page 15

 Database Management System Unit 4

T2 writes uncommitted x that is read by Transaction T3. Suppose at this point T1 fails.T1 must be rolled
back, since T2 is dependent on T1, T2 must be rolled back, and since T3 is dependent on T2, T3 must be
rolled back.

Because of T1 rollback, all T2, T3, and T4 should also be rollback (Cascading dirty read problem).
This phenomenon, in which a single transaction failure leads to a series of transaction rollbacks is called
Cascading rollback.
Dirty Read Problem
When a Transaction reads data from uncommitted write in another transaction, then it is known as Dirty
Read. If that writing transaction failed, and that written data may updated again. Therefore, this
causes Dirty Read Problem. In other words, Reading the data written by an uncommitted transaction is
called as dirty read.
It is called as dirty read because there is always a chance that the uncommitted transaction might roll back
later. Thus, uncommitted transaction might make other transactions read a value that does not even exist.
This leads to inconsistency of the database.
For example, let’s say transaction 1 updates a row and leaves it uncommitted, meanwhile, Transaction 2
reads the updated row. If transaction 1 rolls back the change, transaction 2 will have read data that is
considered never to have existed.

Prepared By- Charu Kavadia Page 16

 Database Management System Unit 4

There will not be any Dirty Read problem, if a transaction is reading from another committed transaction.
So, no rollback is required.

(ii) 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. That means
there must not be Dirty Read. Because Dirty Read Problem can cause Cascading Rollback, which is
inefficient.
or
When a transaction is not allowed to read data until the last transaction which has written it is committed
or aborted, these types of schedules are called cascadeless schedules.
Example-

Here, the updated value of X is read by transaction T2 only after the commit of transaction T1. Hence,
the schedule is cascadeless schedule.
Cascadeless Schedule avoids cascading aborts/rollbacks (ACA). Schedules in which transactions read
values only after all transactions whose changes they are going to read commit are called cascadeless
schedules. Avoids that a single transaction abort leads to a series of transaction rollbacks .A strategy to
prevent cascading aborts is to disallow a transaction from reading uncommitted changes from another
transaction in the same schedule.

Prepared By- Charu Kavadia Page 17

 Database Management System Unit 4

In other words, if some transaction Tj wants to read value updated or written by some other transaction
Ti, then the commit of Tj must read it after the commit of Ti.
Example-

Note that Cascadeless schedule allows only committed read operations. However, it allows uncommitted
write operations. Also note that Cascadeless Schedules are always recoverable, but all recoverable
transactions may not be Cascadeless Schedule.
Example: Consider the following schedule involving two transactions T1 and T2.

It is a recoverable schedule but it does not avoid cascading aborts. It can be seen that if T 1 aborts, T2 will
have to be aborted too in order to maintain the correctness of the schedule as T 2 has already read the
uncommitted value written by T 1.
(iii) Strict Schedule - If in a schedule, a transaction is neither allowed to read nor write a data item until the
last transaction that has written it is committed or aborted, then such a schedule is called as a Strict
Schedule.
In other words,
 Strict schedule allows only committed read and write operations.
 Clearly, strict schedule implements more restrictions than cascadeless schedule.
Prepared By- Charu Kavadia Page 18
 Database Management System Unit 4

Example- Consider the following schedule involving 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. Here, transaction Tb reads and
writes the updated or written value of transaction Ta only after the transaction T1 commits. Hence, the
schedule is strict schedule.

2. Non-Recoverable Schedule: If the system doesn’t recover to a regular database state, it is considered a non-
recoverable schedule.
If in a schedule,
 A transaction performs a dirty read operation from an uncommitted transaction
 And commits before the transaction from which it has read the value, then such a schedule is known
as an Irrecoverable Schedule.
Example- Consider the following schedule involving two transactions T1 and T2.

 T2 performs a dirty read operation.

 T2 commits before T1.
 T1 fails later and roll backs.
 The value that T2 had read now stands to be incorrect.
 T2 can’t recover since it has already committed.
And hence, this schedule is non-recoverable.

Prepared By- Charu Kavadia Page 19