Page 158 - DCAP402_DCAO204_DATABASE MANAGEMENT SYSTEM_MANAGING DATABASE

Unit 9: Transaction Management

still a possibility that it may be aborted, since the actual output may still, be temporarily Notes
residing in main memory, and thus a hardware failure may stop its successful completion.
When the database system writes out successfully the output information to disk, then the
transaction enters the committed state.
A transaction may also enters the failed state from the active state or from the partially committed
state after the system determines that the transaction can no longer proceed with its normal
execution because of hardware failure or logical errors. Such a transaction must be rolled back
and the database has been restored to its state prior to the start of the transaction. Then, it is
known as the aborted state. At this state, the system has two options as follows:
1. Restart the Transaction: It can restart the transaction, but only if the transaction was
aborted as a result of some hardware failure or software error. A restarted transaction is
considered to be a new transaction.

2. Kill the Transaction: It can kill the transaction because of some internal logical error that
can be corrected only by rewriting the application program, or because the input was bad.

Task When a transaction enter into the failed state?

9.3 Implementation of Atomicity and Durability

Transactions can be incomplete for three kinds of reasons. First, a transaction can be aborted, or
terminated unsuccessfully, by the DBMS because some anomaly arises during execution. If a
transaction is aborted by the DBMS for some internal reason, it is automatically restarted and
executed anew. Second, the system may crash (e.g., because the power supply is interrupted)
while one or more transactions are in progress. Third, a transaction may encounter an unexpected
situation (for example, read an unexpected data value or be unable to access some disk) and
decide to abort (i.e., terminate itself).

Of course, since users think of transactions as being atomic, a transaction that is interrupted in
the middle may leave the database in an inconsistent state. Thus a DBMS must find a way to
remove the effects of partial transactions from the database, that is, it must ensure transaction
atomicity: either all of a transaction’s actions are carried out, or none are. A DBMS ensures
transaction atomicity by undoing the actions of incomplete transactions. This means that users
can ignore incomplete transactions in thinking about how the database is modified by transactions
over time. To be able to do this, the DBMS maintains a record, called the log, of all writes to the
database. The log is also used to ensure durability: If the system crashes before the changes made
by a completed transaction are written to disk, the log is used to remember and restore these
changes when the system restarts.
The DBMS component that ensures atomicity and durability is called the recovery manager.

9.4 Concurrent Execution

Transaction-processing systems usually allow multiple transactions to run concurrently (at the
same time) known as concurrent execution of transactions. The DBMS interleaves (inter changes)
the actions of different transactions to improve performance, but not all interleavings should be
allowed. Because allowing multiple transactions 16 update data concurrently causes several
good reasons as well as several complications with the consistency of the database, which are
illustrated as follows:

LOVELY PROFESSIONAL UNIVERSITY 151