Transaction

o The transaction is a set of logically related operation. It contains a group of tasks.

o A transaction is an action or series of actions. It is performed by a single user to perform
operations for accessing the contents of the database.
Example: Suppose an employee of bank transfers Rs 800 from X's account to Y's account. This
small transaction contains several low-level tasks:
X's Account
1. Open_Account(X) Y's Account
2. Old_Balance = X.balance
1. Open_Account(Y)
3. New_Balance = Old_Balance - 800 2. Old_Balance = Y.balance
4. X.balance = New_Balance 3. New_Balance = Old_Balance + 800
5. Close_Account(X) 4. Y.balance = New_Balance
Operations of Transaction: 5. Close_Account(Y)
Following are the main operations of transaction:
Read(X): Read operation is used to read the value of X from the database and stores it in a
buffer in main memory.
Write(X): Write operation is used to write the value back to the database from the buffer.
Let's take an example to debit transaction from an account which consists of following
operations:
1. 1. R(X);
2. 2. X = X - 500;
3. 3. W(X);
Let's assume the value of X before starting of the transaction is 4000.
D
But it may be possible that because of the failure of hardware, software or power, etc. that
transaction may fail before finished all the operations in the set.
For example: If in the above transaction, the debit transaction fails after executing operation 2
then X's value will remain 4000 in the database which is not acceptable by the bank. To solve
this problem, we have two important operations:
Commit: It is used to save the work done permanently.
Rollback: It is used to undo the work done.

Transaction property
From the definition of transaction it is clear that a single transaction may consists of a sequence
of operations which are executed on the database internally. Once the transaction is being
submitted, it should perform all the operations that are part of it and finally when it is completed,
it should notify the success or failure and the changes made by the transaction to the user.
When the multiple user submit the truncations concurrently i.e. at the same time, the database
may result in an inconsistent state due to overlapping of transactions. So, far a transaction to
achieve data integrity in case of concurrent access and system failures, the transaction should
have the properties of atomicity, consistency, isolation and durability. These properties are called
ACID properties derived from the first letter of the property.

What is Transaction?
It is a collection of operations that form a single logical unit of work. The transaction has four
properties. These are used to maintain consistency in a database, before and after the transaction.
The various operations that form a transaction typically include adding some new data,

Page | 1
modifying the existing data, accessing existing data or a combination of these. The ACID
properties are as follows:
Property of Transaction
Atomicity
Consistency
Isolation
Durability

1. Atomicity
o ○ The phrase “all or nothing” describes the first ACID property i.e. atomicity.
o It states that all operations of the transaction take place at once if not, the transaction is
aborted.
o There is no midway, i.e., the transaction cannot occur partially. Each transaction is
treated as one unit and either run to completion or is not executed at all.
Features of Atomicity Property:
o Either all operations that are part of the transaction are completed or none.
o It is maintained in the presence of disk, CPU, database software and application software
failures.
o It is maintained in the presence of deadlocks.
o It can be locked at the system level as well as at the session level
o Ensuring atomicity is the responsibility of the database system itself.
AD
Atomicity involves the following two operations:
Abort: If a transaction aborts then all the changes made are not visible.
Commit: If a transaction commits then all the changes made are visible.
Example: Let's assume that following transaction T consisting of T1 and T2. A consists of Rs
600 and B consists of Rs 300. Transfer Rs 100 from account A to account B.

T1 T2

Read(A) Read(B)
A:= A-100 Y:= Y+100
Write(A) Write(B)
After completion of the transaction, A consists of Rs 500 and B consists of Rs 400.
If the transaction T fails after the completion of transaction T1 but before completion of
transaction T2, then the amount will be deducted from A but not added to B. This shows the
inconsistent database state. In order to ensure correctness of database state, the transaction must
be executed in entirety.
The mechanism for maintaining atomicity is done by the DBMS keeping track of the old values
of the data on which the write operation is performed and if the transaction does not complete its
execution, the old values are restored to appear as if the transaction had never been executed.
AD
Consistency
o The phrase “no violation of integrity constraints” describes the property of consistency.
o The integrity constraints are maintained so that the database is consistent before and after
the transaction.

Page | 2
 o The execution of a transaction will leave a database in either its prior stable state or a new
stable state.
o The consistent property of database states that every transaction sees a consistent
database instance.
o The transaction is used to transform the database from one consistent state to another
consistent state.
For example: The total amount must be maintained before or after the transaction.
1. Total before T occurs = 600+300=900
2. Total after T occurs= 500+400=900
Therefore, the database is consistent. In the case when T1 is completed but T2 fails, then
inconsistency will occur.
Without a consistent property, money can be credited or debited by the transaction. It is the
responsibility of the application programmers who code the transaction to maintain the
consistency for individual transactions by enforcing consistency constraints on the database.
Isolation
o It shows that the data which is used at the time of execution of a transaction cannot be
used by the second transaction until the first one is completed.
o In isolation, if the transaction T1 is being executed and using the data item X, then that
data item can't be accessed by any other transaction T2 until the transaction T1 ends.
o The concurrency control subsystem of the DBMS enforced the isolation property.

Implementing Isolation:
When more than one transaction is executing concurrently then there can be problems even if
each transaction satisfies the atomicity as well as the consistency property. These problems are
there due to the overlapping of the concurrently running transactions i.e. when transaction
interfere with one another
AD
Example: Now let us consider the two transactions T1 and T2 executing concurrently. The
transaction T1 is transferring amount Rs 750 from account A to account B and transaction T2
transfers 20% of amount from account A to account B. Suppose initially account balances in
Account A and B are Rs 5000 and 8000 respectively.

Now the schedule for the transactions T1 and T2 running concurrently as explained in the
figure below:

Schedule 1: Consistent State

T1 T2 Description/Status

Read (A) Rs 5000

A : = A – 750 Rs 4250
Write (A) Store to A
Read (A) Rs 4250
temp : = A * 0.2 Rs 850
A : = A – temp Rs 3400
Write (A) Store in A
Read (B) Rs 8000

Page | 3
 B := B + 750 Rs 8750
Write (B) Store to B
Read (B) Rs 8750
B := B + temp Rs 9600
Write (B) Store in B

Schedule 2: Inconsistent State

T1 T2 Description/Status

Read (A) Rs 5000

A : = A – 750 Rs 4250
Read (A) Rs 5000
temp : = A * 0.2 Rs 1000
A : = A – temp Rs 4000
Write (A) Store to A = 4000
Read (B) Rs 8000
Write (A) Store to A = 4250
Read (B) Rs 8000
B := B + 750 Rs 8750
Write (B) Store to B = 8750
B := B + temp Rs 9600
Write (B) Store to B = 9000
The schedule 1 results in a consistent state of the database as it shows the sum of the accounts A
and B to be Rs 13000 before and after the execution of transaction.
AD
Now consider the schedule 2, in which the transaction T1 has performed write operation on the
account A, thus updating its value to Rs 4250 by reducing the amount of Rs 750 from account A
and during this time, another transaction T2 reads the balance of account A i.e. Rs 5000.
Now it calculates the 20% amount of account A and stores it in the temp variable. Thereafter, it
updates the account A balance to Rs 4000 by deducting temp variable value i.e. Rs 1000 from
initial balance of account A i.e. Rs 5000. Now it also reads the balance of account B. Before
executing further transaction T1 gains control and performs the write operation on account A.
Now transaction T1 and the value of balance in account B so it will update the value of B to Rs
9000 instead of Rs 9750. Thus, the sum of account A and B turns out to be Rs 13250 = (4250 +
9000) which leads to inconsistency as it should be 13000.
One of the possible solutions to the above problem is to execute the above transactions serially
i.e. one after the other. But it can also lead to problems. Suppose a long transaction is being done
first then all the other transactions will have to wait in the queue even through some transactions
do not interfere with each other. So there is no need to wait in the queue for such transactions.
However, concurrent execution of a group of concurrent transactions offers performance
benefits. So DBMS has developed other solutions that allow the execution of multiple
transactions concurrently without any problem. One of the possible methods is explained in
schedule 1. This is the requirement of the isolation property which demands that data used during
Page | 4
execution of one transaction cannot be used by the second until the first transaction is completed.
Isolation property is handled by the concurrent control components of the DBMS.

Durability
o The durability property is used to indicate the performance of the database's consistent
state. It states that the transaction made the permanent changes.
o They cannot be lost by the erroneous operation of a faulty transaction or by the system
failure. When a transaction is completed, then the database reaches a state known as the
consistent state. That consistent state cannot be lost, even in the event of a system's
failure.
o The recovery subsystem of the DBMS has the responsibility of Durability property.
The DBMS maintains a record called a log that tracks all writes to the database. The log helps
ensure durability. If the system crashes before the changes made by a completed transaction are
written to the disk, the log is used to remember these changes when the system restarts.

Schedule
A series of operation from one transaction to another transaction is known as schedule. It is used
to preserve the order of the operation in each of the individual transaction.

1. Serial Schedule
The serial schedule is a type of schedule where one transaction is executed completely before
starting another transaction. In the serial schedule, when the first transaction completes its cycle,
then the next transaction is executed.
For example: Suppose there are two transactions T1 and T2 which have some operations. If it
has no interleaving of operations, then there are the following two possible outcomes:
1. Execute all the operations of T1 which was followed by all the operations of T2.
2. Execute all the operations of T1 which was followed by all the operations of T2.
o In the given (a) figure, Schedule A shows the serial schedule where T1 followed by T2.
o In the given (b) figure, Schedule B shows the serial schedule where T2 followed by T1.
2. Non-serial Schedule
o If interleaving of operations is allowed, then there will be non-serial schedule.

Page | 5
 o It contains many possible orders in which the system can execute the individual
operations of the transactions.
o In the given figure (c) and (d), Schedule C and Schedule D are the non-serial schedules. It
has interleaving of operations.
AD
AD
3. Serializable schedule
o The serializability of schedules is used to find non-serial schedules that allow the
transaction to execute concurrently without interfering with one another.
o It identifies which schedules are correct when executions of the transaction have
interleaving of their operations.
o A non-serial schedule will be serializable if its result is equal to the result of its
transactions executed serially.

Here,
Schedule A and Schedule B are serial schedule.
Schedule C and Schedule D are Non-serial schedule.
esting of Serializability
Page | 6
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).

o 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.
o 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.
Precedence graph for schedule S1:

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

Page | 7
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
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
AD
Precedence graph for schedule S2:

The precedence graph for schedule S2 contains no cycle that's why ScheduleS2 is serializable.
Conflict Serializable Schedule
o A schedule is called conflict serializability if after swapping of non-conflicting
operations, it can transform into a serial schedule.
o The schedule will be a conflict serializable if it is conflict equivalent to a serial schedule.
Conflicting Operations
The two operations become conflicting if all conditions satisfy:
1. Both belong to separate transactions.
2. They have the same data item.

Page | 8
 3. They contain at least one write operation.
Example:
Swapping is possible only if S1 and S2 are logically equal.

Here, S1 = S2. That means it is non-conflict.

Here, S1 ≠ S2. That means it is conflict.

Conflict Equivalent
In the conflict equivalent, one can be transformed to another by swapping non-conflicting
operations. In the given example, S2 is conflict equivalent to S1 (S1 can be converted to S2 by
swapping non-conflicting operations).
Two schedules are said to be conflict equivalent if and only if:
1. They contain the same set of the transaction.
2. If each pair of conflict operations are ordered in the same way.
AD

Page | 9
Example:

Schedule S2 is a serial schedule because, in this, all operations of T1 are performed before
starting any operation of T2. Schedule S1 can be transformed into a serial schedule by swapping
non-conflicting operations of S1.
After swapping of non-conflict operations, the schedule S1 becomes:
T1 T2

Read(A)
Write(A)
Read(B) Read(A)
Write(B) Write(A)
Read(B)
Write(B)
Since, S1 is conflict serializable.

View Serializability
o A schedule will view serializable if it is view equivalent to a serial schedule.
o If a schedule is conflict serializable, then it will be view serializable.
o The view serializable which does not conflict serializable contains blind writes.
View Equivalent
Two schedules S1 and S2 are said to be view equivalent if they satisfy the following conditions:
1. Initial Read
An initial read of both schedules must be the same. Suppose two schedule S1 and S2. In schedule
S1, if a transaction T1 is reading the data item A, then in S2, transaction T1 should also read A.

Page | 10
Above two schedules are view equivalent because Initial read operation in S1 is done by T1 and
in S2 it is also done by T1.
AD
2. Updated Read
In schedule S1, if Ti is reading A which is updated by Tj then in S2 also, Ti should read A which
is updated by Tj.

Above two schedules are not view equal because, in S1, T3 is reading A updated by T2 and in
S2, T3 is reading A updated by T1.
3. Final Write
A final write must be the same between both the schedules. In schedule S1, if a transaction T1
updates A at last then in S2, final writes operations should also be done by T1.

Above two schedules is view equal because Final write operation in S1 is done by T3 and in S2,
the final write operation is also done by T3.
Example:

Page | 11
 Schedule S
With 3 transactions, the total number of possible schedule
1. = 3! = 6
2. S1 = <T1 T2 T3>
3. S2 = <T1 T3 T2>
4. S3 = <T2 T3 T1>
5. S4 = <T2 T1 T3>
6. S5 = <T3 T1 T2>
7. S6 = <T3 T2 T1>
Taking first schedule S1:

Schedule S1
Step 1: final updation on data items
In both schedules S and S1, there is no read except the initial read that's why we don't need to
check that condition.
Step 2: Initial Read
The initial read operation in S is done by T1 and in S1, it is also done by T1.
Step 3: Final Write
AD
The final write operation in S is done by T3 and in S1, it is also done by T3. So, S and S1 are
view Equivalent.
The first schedule S1 satisfies all three conditions, so we don't need to check another schedule.
Hence, view equivalent serial schedule is:
1. T1 → T2 → T3

Recoverability of Schedule
Sometimes a transaction may not execute completely due to a software issue, system crash or
hardware failure. In that case, the failed transaction has to be rollback. But some other
transaction may also have used value produced by the failed transaction. So we also have to
rollback those transactions.

Page | 12
The above table 1 shows a schedule which has two transactions. T1 reads and writes the value of
A and that value is read and written by T2. T2 commits but later on, T1 fails. Due to the failure,
we have to rollback T1. T2 should also be rollback because it reads the value written by T1, but
T2 can't be rollback because it already committed. So this type of schedule is known as
irrecoverable schedule.
Irrecoverable schedule: The schedule will be irrecoverable if Tj reads the updated value of Ti
and Tj committed before Ti commit.

The above table 2 shows a schedule with two transactions. Transaction T1 reads and writes A,
and that value is read and written by transaction T2. But later on, T1 fails. Due to this, we have
to rollback T1. T2 should be rollback because T2 has read the value written by T1. As it has not
committed before T1 commits so we can rollback transaction T2 as well. So it is recoverable
with cascade rollback.
Recoverable with cascading rollback: The schedule will be recoverable with cascading
rollback if Tj reads the updated value of Ti. Commit of Tj is delayed till commit of Ti.

Page | 13
The above Table 3 shows a schedule with two transactions. Transaction T1 reads and write A
and commits, and that value is read and written by T2. So this is a cascade less recoverable
schedule.

Page | 14