What is a Transaction?

A transaction is an event which occurs on the database. Generally a transaction reads a value from the
database or writes a value to the database. Although a transaction can both read and write on the database,
there are some fundamental differences between these two classes of operations.

To read a database object, it is first brought into main memory (in some frame of the buffer pool) from
disk, and then its value is copied into a program. This is done by read operation. To write a database
object, in-memory copy of the object is first modified and then written to disk. This all is done by write
operation.

A read operation does not change the image of the database in any way. But a write operation, whether
performed with the intention of inserting, updating or deleting data from the database, changes the image
of the database. That is, we may say that these transactions bring the database from an image which
existed before the transaction occurred (called the Before Image or BFIM) to an image which exists after
the transaction occurred (called the After Image or AFIM).

To read a database object, it is first brought into main memory (in some frame of the buffer pool) from
disk, and then its value is copied into a program. This is done by read operation. To write a database
object, in-memory copy of the object is first modified and then written to disk. This all is done by write
operation.

Concept of a Transaction

A user writes data access/update programs in terms of the high-level query and update language
supported by the DBMS. To understand how the DBMS handles such requests, with respect to
concurrency control and recovery, it is convenient to regard an execution of a user program, or
transaction, as a series of reads and writes of database objects:

1. To read a database object, it is first brought into main memory (specifically, some frame in the buffer
pool) from disk, and then its value is copied into a program variable.

2. To write a database object, an in-memory copy of the object is first modified and then written to disk.

The Four Properties of Transactions

Every transaction, for whatever purpose it is being used, has the following four properties. Taking the
initial letters of these four properties we collectively call them the ACID Properties. Here we try to
describe them and explain them.

Atomicity: This means that either all of the instructions within the transaction will be reflected in the
database, or none of them will be reflected.

Say for example, we have two accounts A and B, each containing Rs 1000/-. We now start a transaction
to deposit Rs 100/- from account A to Account B.

Read A;

A = A – 100;
Write A;

Read B;

B = B + 100;

Write B;

The transaction has 6 instructions to extract the amount from A and submit it to B. The AFIM will show
Rs 900/- in A and Rs 1100/- in B.

Now, suppose there is a power failure just after instruction 3 (Write A) has been complete. What happens
now? After the system recovers the AFIM will show Rs 900/- in A, but the same Rs 1000/- in B. It would
be said that Rs 100/- evaporated in thin air for the power failure. Clearly such a situation is not
acceptable.

Consistency

Each transaction, run by itself with no concurrent execution of other transactions, must preserve the
consistency of the database. This property is called consistency, and the DBMS assumes that it holds for
each transaction. Ensuring this property of a transaction is the responsibility of the user.

To give better performance, every database management system supports the execution of multiple
transactions at the same time, using CPU Time Sharing. Concurrently executing transactions may have to
deal with the problem of sharable resources, i.e. resources that multiple transactions are trying to
read/write at the same time. For example, we may have a table or a record on which two transaction are
trying to read or write at the same time. Careful mechanisms are created in order to prevent
mismanagement of these sharable resources, so that there should not be any change in the way a
transaction performs. A transaction which deposits Rs 100/- to account A must deposit the same amount
whether it is acting alone or in conjunction with another transaction that may be trying to deposit or
withdraw some amount at the same time.

Isolation

A transaction executes in isolation without any interference from any other transaction. It should not
make visible to other transaction until it is successfully completed.  Transaction should be visible till
they are committed

In case multiple transactions are executing concurrently and trying to access a sharable resource at the
same time, the system should create an ordering in their execution so that they should not create any
anomaly in the value stored at the sharable resource. In case multiple transactions are executing
concurrently and trying to access a sharable resource at the same time, the system should create an
ordering in their execution so that they should not create any anomaly in the value stored at the sharable
resource.

There are several ways to achieve this and the most popular one is using some kind of locking
mechanism. It states that a transaction must first lock the data item that it wishes to access, and release the
lock when the accessing is no longer required. Once a transaction locks the data item, other transactions
wishing to access the same data item must wait until the lock is released.

Durability

It states that once a transaction has been complete the changes it has made should be permanent. 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 State

1. Active State: This is the initial state of a transaction, the transaction stays in this state while it is
starting execution.

2. Partially Committed State: This transaction state occurs after the final (last) statement of the
transaction has been executed.

3. Failed State: This transaction state occurs after the discovery that normal execution can no longer
proceed.

4. Aborted State: This transaction state occurs after the transaction has been rolled back and the database
has been restored to its state prior to the start of the transaction.

5.: Committed State This transaction state occurs after the successful completion of the transaction.
Active state

• The active state is the first state of every transaction. In this state, the transaction is being executed.

• For example: Insertion or deletion or updating a record is done here. But all the records are still not
saved to the database.

Partially committed

• In the partially committed state, a transaction executes its final operation, but the data is still not saved
to the database.

• In the total mark calculation example, a final display of the total marks step is executed in this state.

Committed

A transaction is said to be in a committed state if it executes all its operations successfully. In this state,
all the effects are now permanently saved on the database system.

Failed state

 If any of the checks made by the database recovery system fails, then the transaction is said to be in the
failed state.

• In the example of total mark calculation, if the database is not able to fire a query to fetch the marks,
then the transaction will fail to execute.

Aborted

• If any of the checks fail and the transaction has reached a failed state then the database recovery system
will make sure that the database is in its previous consistent state. If not then it will abort or roll back the
transaction to bring the database into a consistent state.

• If the transaction fails in the middle of the transaction then before executing the transaction, all the
executed transactions are rolled back to its consistent state. • After aborting the transaction, the database
recovery module will select one of the two operations: