A transaction can be defined as a group of tasks.

A single task is the

minimum processing unit which cannot be divided further.

A transaction is a set of logically related operations.

A Database Transaction is a logical unit of processing in a DBMS which

entails one or more database access operation.

For example, you are transferring money from your bank account to your
friend’s account, the set of operations would be like this:
Simple Transaction Example

1. Read your account balance

2. Deduct the amount from your balance
3. Write the remaining balance to your account
4. Read your friend’s account balance
5. Add the amount to his account balance
6. Write the new updated balance to his account

In DBMS, we write the above 6 steps transaction like this:

Lets say your account is A and your friend’s account is B, you are
transferring 10000 from A to B, the steps of the transaction are:

1. R(A);
2. A = A - 10000;
3. W(A);
4. R(B);
5. B = B + 10000;
6. W(B);
In the above transaction R refers to the Read operation and W refers to the write operation.

Transaction failure in between the operations

Now that we understand what transaction is, we should understand what

are the problems associated with it.

The main problem that can happen during a transaction is that the
transaction can fail before finishing the all the operations in the set.
This can happen due to power failure, system crash etc. This is a
serious problem that can leave database in an inconsistent state.
Assume that transaction fail after third operation (see the example above)
then the amount would be deducted from your account but your friend will
not receive it.

To solve this problem, we have the following two operations

Commit: If all the operations in a transaction are completed successfully

then commit those changes to the database permanently.

Rollback: If any of the operation fails then rollback all the changes done by
previous operations.

Even though these operations can help us avoiding several issues

that may arise during transaction but they are not sufficient when
two transactions are running concurrently. To handle those
problems we need to understand database ACID properties.

To ensure the integrity of data during a transaction (A transaction is a

unit of program that updates various data items, read more about it
here), the database system maintains the following properties. These
properties are widely known as ACID properties:

 Atomicity: This property ensures that either all the operations of a

transaction reflect in database or none. Let’s take an example of
banking system to understand this: Suppose Account A has a balance
of 400$ & B has 700$. Account A is transferring 100$ to Account B.
This is a transaction that has two operations

a) Debiting 100$ from A’s balance

b) Creating 100$ to B’s balance.

Let’s say first operation passed successfully while second failed, in this
case A’s balance would be 300$ while B would be having 700$ instead
of 800$. This is unacceptable in a banking system. Either the
transaction should fail without executing any of the operation or it
should process both the operations. The Atomicity property ensures
that.

 Consistency: To preserve the consistency of database, the

execution of transaction should take place in isolation (that
means no other transaction should run concurrently when there
is a transaction already running).
 For example account A is having a balance of 400$ and it is
transferring 100$ to account B & C both. So we have two transactions
here. Let’s say these transactions run concurrently and both the
transactions read 400$ balance, in that case the final balance of A
would be 300$ instead of 200$. This is wrong. If the transaction were
to run in isolation then the second transaction would have read the
correct balance 300$ (before debiting 100$) once the first transaction
went successful.

 Isolation: For every pair of transactions, one transaction should

start execution only when the other finished execution. I have
already discussed the example of Isolation in the Consistency property
above.

 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.

DBMS Transaction States Diagram

There are set of five different states, which a transaction needs to go

through. They are active, partially committed, committed, failed and
aborted.
 Active – This is the state when the transaction is entered into the active
state. Operations like read, write or other operations are performed by the
transaction by remaining in this state.
If a transaction is in execution then it is said to be in active state. It doesn’t
matter which step is in execution, until unless the transaction is executing,
it remains in active state.

Partially Committed State

As we can see in the above diagram that a transaction goes into “partially
committed” state from the active state when there are read and write
operations present in the transaction.

A transaction contains number of read and write operations. Once the whole
transaction is successfully executed, the transaction goes into partially
committed state where we have all the read and write operations performed
on the main memory (local memory) instead of the actual database.

The reason why we have this state is because a transaction can fail during
execution so if we are making the changes in the actual database instead of
local memory, database may be left in an inconsistent state in case of any
failure. This state helps us to rollback the changes made to the
database in case of a failure during execution.

Only once the last statement of the transaction is executed, the transaction
enters this state.

 Committed – After the transaction is successfully completed, and the

commit signal is issued by the system check, the transaction enters this
state.
If a transaction completes the execution successfully then all the changes
made in the local memory during partially committed state are
permanently stored in the database.

Failed State

If a transaction is executing and a failure occurs, either a hardware failure

or a software failure then the transaction goes into failed state from the
active state.
When it is realised that the transaction cannot proceed with the normal
execution or when there is a failure on the system check, the transaction
enters this failed state either from the active state or partially committed
state.

Aborted – The state when the transaction has been completely rolled back
after restoring the failure database

if a transaction fails during execution then the transaction goes into a failed
state. The changes made into the local memory (or buffer) are rolled back to
the previous consistent state and the transaction goes into aborted state
from the failed state.

We know that transactions are set of instructions and these instructions

perform operations on database. When multiple transactions are running
concurrently then there needs to be a sequence in which the operations are
performed because at a time only one operation can be performed on the
database. This sequence of operations is known as Schedule.

Lets take an example to understand what is a schedule in DBMS.

DBMS Schedule example

The following sequence of operations is a schedule. Here we have two

transactions T1 & T2 which are running concurrently.

This schedule determines the exact order of operations that are going to be
performed on database. In this example, all the instructions of transaction
T1 are executed before the instructions of transaction T2, however this is
not always necessary and we can have various types of schedules which we
will discuss in this article.

T1 T2
---- ----
R(X)
W(X)
R(Y)
R(Y)
R(X)
W(Y)

Types of Schedules in DBMS

We have various types of schedules in DBMS. Lets discuss them one
by one.

Serial Schedule
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. The example we have seen above is the serial
schedule.

Lets take another example.

Serial Schedule example

Here R refers to the read operation and W refers to the write operation. In this
example, the transaction T2 does not start execution until the transaction T1 is
finished.

T1 T2
---- ----
R(A)
R(B)
W(A)
commit
R(B)
R(A)
W(B)
commit

Strict Schedule
In Strict schedule, if the write operation of a transaction precedes a
conflicting operation (Read or Write operation) of another transaction
then the commit or abort operation of such transaction should also
precede the conflicting operation of other transaction.

Lets take an example.

Strict Schedule example

Lets say we have 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.

Ta Tb
----- -----
R(X)
R(X)
W(X)
commit
W(X)
R(X)
commit

Here the write operation W(X) of Ta precedes the conflicting

operation (Read or Write operation) of Tb so the conflicting operation
of Tb had to wait the commit operation of Ta.

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.
Cascadeless Schedule example
For example, lets say we have two transactions Ta and Tb. Tb is going
to read the value X after the W(X) of Ta then Tb has to wait for the
commit operation of transaction Ta before it reads the X.

Ta Tb
----- -----
R(X)
W(X)
W(X)
commit
R(X)
W(X)
commit

Recoverable Schedule
In Recoverable schedule, if a transaction is reading a value which has
been updated by some other transaction then this transaction can
commit only after the commit of other transaction which is updating
value.

Recoverable Schedule example

Here Tb is performing read operation on X after the Ta has made
changes in X using W(X) so Tb can only commit after the commit
operation of Ta.

Ta Tb
----- -----
R(X)
W(X)
R(X)
W(X)
R(X)
commit
commit

DBMS Serializability
When multiple transactions are running concurrently then there is a
possibility that the database may be left in an inconsistent state.
Serializability is a concept that helps us to check which schedules are
serializable. A serializable schedule is the one that always leaves the
database in consistent state.

What is a serializable schedule?

A serializable schedule always leaves the database in consistent state.
A serial schedule is always a serializable schedule because in serial
schedule, a transaction only starts when the other transaction finished
execution. However a non-serial schedule needs to be checked for
Serializability.

A non-serial schedule of n number of transactions is said to be

serializable schedule, if it is equivalent to the serial schedule of those
n transactions. A serial schedule doesn’t allow concurrency, only one
transaction executes at a time and the other starts when the already
running transaction finished.