UNIT 5

OVERVIEW OF TRANSACTION MANAGEMENT

ACID PROPERTIES IN DBMS
A transaction is a single logical unit of work which accesses and possibly modifies the
contents of a database. Transactions access data using read and write operations.
In order to maintain consistency in a database, before and after the transaction, certain
properties are followed. These are called ACID properties.

ATOMICITY

The term atomicity defines that the data remains atomic. It means if any operation is performed
on the data, either it should be performed or executed completely or should not be executed at
all.

If the transaction fails after completion of T1 but before completion of T2.( say, after write(X)
but before write(Y)), then the amount has been deducted from X but not added to Y.
 CONSISTENCY
The word consistency means that the value should remain preserved always. In DBMS, the
integrity of the data should be maintained, which means if a change in the database is made, it
should remain preserved always.

EXAMPLE:

The total amount before and after the transaction must be maintained.
Total before T occurs = 500 + 200 = 700.
Total after T occurs = 400 + 300 = 700.
Therefore, the database is consistent. Inconsistency occurs in case T1 completes but T2
fails. As a result, T is incomplete.

ISOLATION
The term 'isolation' means separation. In DBMS, Isolation is the property of a database where no data
should affect the other one and may occur concurrently.

DURABILITY
Durability ensures the permanency of something. In DBMS, the term durability ensures that the data
after the successful execution of the operation becomes permanent in the database.

The durability of the data should be so perfect that even if the system fails or leads to a crash, the
database still survives.

However, if gets lost, it becomes the responsibility of the recovery manager for ensuring the
durability of the database.

For committing the values, the COMMIT command must be used every time we make changes.

TRANSACTION MANAGEMENT IN DBMS

DBMS TRANSACTION STATES
A transaction is a set of logically related operations. 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
This whole set of operations can be called a transaction.
In this guide, we will discuss the states of a transaction in DBMS. A transaction in DBMS can
be in one of the following states.
DBMS Transaction States Diagram

Active State

As we have discussed in the DBMS transaction introduction that a transaction is a sequence of

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

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.
Committed 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. You can also see in the
above diagram that a transaction goes from partially committed state to committed state when
everything is successful.

Aborted State

As we have seen above, 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. Refer the diagram to see the
interaction between failed and aborted state.

TYPES OF SCHEDULES IN DBMS

Schedule, as the name suggests, is a process of lining the transactions and executing them one by
one. When there are multiple transactions that are running in a concurrent manner and the order of
operation is needed to be set so that the operations do not overlap each other, Scheduling is brought
into play and the transactions are timed accordingly.

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

Example: Consider the following schedule involving two transactions T1 and T2.

T1 T2

R(A)
W(A)
R(B)
W(B)
R(A)
R(B)

where R(A) denotes that a read operation is performed on some data item ‘A’ This is a
serial schedule since the transactions perform serially in the order T1 —> T2.

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. It can be of two types namely, Serializable
and Non-Serializable Schedule.

The Non-Serial Schedule can be divided further into Serializable and Non-Serializable.