Transaction Management in DBMS

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

Transaction failure in between the operations

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.
Facts about Database Transactions

A transaction is a program unit whose execution may or may not change the
contents of a database.
 The transaction is executed as a single unit.
 If the database operations do not update the database but only retrieve data, this
type of transaction is called a read-only transaction.
A successful transaction can change the database from one CONSISTENT
STATE to another
 DBMS transactions must be atomic, consistent, isolated and durable.
States of Transactions

The various states of a Database Transaction are listed below

State Transaction types

Active State A transaction enters into an active state when the

execution process begins. During this state read or
write operations can be performed.
Partially Committed A transaction goes into the partially committed state
after the end of a transaction.
Committed State When the transaction is committed to state, it has
already completed its execution successfully.
Moreover, all of its changes are recorded to the
database permanently.
Failed State A transaction considers failed when any one of the
checks fails or if the transaction is aborted while it is
in the active state.
Terminated State State of transaction reaches terminated state when
certain transactions which are leaving the system can't
be restarted.

State Transition Diagram for a Database Transaction

Details of State Transition Diagram:

1. Once a transaction starts execution, it becomes active. It can issue READ or

WRITE operation.
 2. Once the READ and WRITE operations complete, the transactions becomes
partially committed state.
3. Next, some recovery protocols need to ensure that a system failure will not
result in an inability to record changes in the transaction permanently. If this
check is a success, the transaction commits and enters into the committed
state.
4. If the check is a fail, the transaction goes to the Failed state.
5. If the transaction is aborted while it's in the active state, it goes to the failed
state. The transaction should be rolled back to undo the effect of its write
operations on the database.
6. The terminated state refers to the transaction leaving the system.

ACID Properties in DBMS

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
By this, we mean that either the entire transaction takes place at once or doesn’t happen
at all. There is no midway i.e. transactions do not occur partially. Each transaction is
considered as one unit and either runs to completion or is not executed at all. It involves
the following two operations.
—Abort: If a transaction aborts, changes made to database are not visible.
—Commit: If a transaction commits, changes made are visible.
Atomicity is also known as the ‘All or nothing rule’.

Consider the following transaction T consisting of T1 and T2: Transfer of 100 from
account X to account Y.
If the transaction fails after completion of T1 but before completion of T2.( say,
after write(X) but before write(Y)), then amount has been deducted from X but not
added to Y. This results in an inconsistent database state. Therefore, the transaction must
be executed in entirety in order to ensure correctness of database state.

Consistency
This means that integrity constraints must be maintained so that the database is consistent
before and after the transaction. It refers to the correctness of a database.

Referring to the example above,

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, database is consistent. Inconsistency occurs in case T1 completes
but T2 fails. As a result T is incomplete.

Isolation
This property ensures that multiple transactions can occur concurrently without leading to
the inconsistency of database state. Transactions occur independently without
interference. Changes occurring in a particular transaction will not be visible to any other
transaction until that particular change in that transaction is written to memory or has
been committed. This property ensures that the execution of transactions concurrently
will result in a state that is equivalent to a state achieved these were executed serially in
some order.

Let X= 500, Y = 500.

Consider two transactions T and T”.
Suppose T has been executed till Read (Y) and then T’’ starts. As a result , interleaving of
Operations takes place due to which T’’ reads correct value of X but incorrect value of Y and
sum computed by
T’’: (X+Y = 50, 000+500=50, 500)
is thus not consistent with the sum at end of transaction:
T: (X+Y = 50, 000 + 450 = 50, 450).
This results in database inconsistency, due to a loss of 50 units. Hence, transactions must take
place in isolation and changes should be visible only after they have been made to the main
memory.

Durability:
This property ensures that once the transaction has completed execution, the
updates and modifications to the database are stored in and written to disk and they
persist even if a system failure occurs. These updates now become permanent and
are stored in non-volatile memory. The effects of the transaction, thus, are never
lost.
The ACID properties, in totality, provide a mechanism to ensure correctness and
consistency of a database in a way such that each transaction is a group of
operations that acts a single unit, produces consistent results, acts in isolation from
other operations and updates that it makes are durably stored.

What is a Schedule?
A schedule is a series of operations from one or more transactions. A schedule can
be of two types:
 Serial Schedule: When one transaction completely executes before starting
another transaction, the schedule is called serial schedule. A serial schedule is
always consistent. e.g.; If a schedule S has debit transaction T1 and credit
transaction T2, possible serial schedules are T1 followed by T2 (T1->T2) or
T2 followed by T1 ((T2->T1). A serial schedule has low throughput and less
resource utilization.
 Concurrent Schedule: When operations of a transaction are interleaved with
operations of other transactions of a schedule, the schedule is called
Concurrent schedule. But concurrency can lead to inconsistency in the
database.