Transaction States and Additional Operations:

                                                 A transaction is an atomic unit (or logical unit) of work that should either be completed in its entirety or not done at all. For recovery purposes, the system needs to keep track of when each transaction starts, terminates, and commits or aborts. Therefore, the recovery manager of the DBMS needs to keep track of the following operations:

BEGIN_TRANSACTION: This marks the beginning of transaction execution.

READ or WRITE: These specify read or write operations on the database items that are executed as part of a transaction.

END_TRANSACTION: This specifies that READ and WRITE transaction operations have ended and marks the end of transaction execution. However, at this point it may be necessary to check whether the changes introduced by the transaction can be permanently applied to the database (committed) or whether the transaction has to be aborted because it violates serializability (see Section 21.5) or for some other reason.

COMMIT_TRANSACTION: This signals a successful end of the transaction so that any changes (updates) executed by the transaction can be safely committed to the database and will not be undone.

ROLLBACK (or ABORT): This signals that the transaction has ended unsuccessfully, so that any changes or effects that the transaction may have applied to the database must be undone.

A transaction in a database can be in one of the following states:

Ø  Active

Ø  Partially committed

Ø  Failed

Ø  Aborted

Ø  Committed

Active state:  Initial state:

                             This is the first state of transaction and here the transaction is being executed. For example, updating or inserting or deleting a record is done here. But it is still not saved to the database.

The transaction starts executing from the first instruction begin_transaction, the transaction will be considered in active state. During this state it performs operations READ and WRITE on some data items.

From active state, a transaction can go into one of two states, a partially committed state or a failed state.

Partially committed state – After the execution of final statement:

                 This is the state of a transaction that successfully executing its last or final instruction. That means, if an active transaction reaches and executes the COMMIT statement, then the transaction is said to be in partially committed state.

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

Example:- In the total mark calculation example, final display of the total marks step is executed in this state.

Committed – After successful completion of transaction:

                                       A transaction is said to be in a committed state successfully, executes all its operations without fail. And all the transactions are permanently saved to the database. This step is the last step of a transaction.

 NOTE:

·       After a transaction has entered the committed state, it is not possible to roll back the transaction i.e. we cannot undo the changes the transaction has made because the system has been now updated into a new consistent state.

·       We cannot abort or rollback a committed transaction.

·       From committed state, a transaction can go into terminated state.

Failed – If any failure occurs:

                                 If a transaction cannot proceed to the execution state because of the failure of the system or database, then the transaction is said to be in failed state.

While a transaction is in the active state or in the partially committed state, the issues like transaction failure, user aborting the transaction, concurrency control issues, or any other failure, would happen. If any of these issues are raised, then the execution of the transaction can no longer proceed. At this stage a transaction will go into a failed state.

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. From failed state, a transaction can go into only aborted state.

Aborted – After rolled back to the old consistent state:

                                          If a transaction is failed to execute, then the database recovery system will make sure that the database is in its previous consistent state. If not, it brings the database to consistent state by aborting or rolling back the transaction. If the transaction fails in the middle of the transaction, all the executed transactions are rolled back to it consistent state before executing the transaction. Once the transaction is aborted it is either restarted to execute again or fully killed by the DBMS.

After the failed state, all the changes made by the transaction has to be rolled back and the database has to be restored to its state prior to the start of the transaction. If these actions are completed by the DBMS then the transaction considered to be in aborted state.

From aborted state, a transaction can go into terminated state

Terminated state:

                 This is the last state in the life cycle of a transaction. After entering the committed state or aborted state, the transaction then finally enters into a terminated state where the transaction life cycle finally comes to an end.

We say that a transaction has committed only if it has entered the committed state. Similarly, we say that a transaction has aborted only if it has entered the aborted state. A transaction is said to have terminated if has either committed or aborted.

A transaction starts in the active state. When it finishes its final statement, it enters the partially committed state. At this point, the transaction has completed its execution, but it is still possible that it may have to be aborted, since the actual output may still be temporarily hiding in main memory and thus a hardware failure may preclude its successful completion.

The database system then writes out enough information to disk that, even in the event of a failure, the updates performed by the transaction can be recreated when the system restarts after the failure. When the last of this information is written out, the transaction enters the committed state.