DDBMS - Transaction Processing Systems

DDBMS - Transaction Processing Systems

The different aspects of transaction processing are discussed in this chapter. We will also review the low-level tasks, the transaction states and properties of a transaction used in a transaction. We will look at schedules and the serializability of schedules in the last portion.

Transactions

A transaction is a program executed as a logical data processing unit, including a collection of database operations. One or more database operations, such as inserting , deleting, updating or retrieving data, include the operations performed in a transaction. It is an atomic process that is either fully finished or not carried out at all. A transaction that requires only retrieving data without changing any data is called a read-only transaction.

Each operation at a high level can be split into a number of tasks or operations at a low level. A data update operation can, for example, be split into three tasks-

read_item() − reads data item from storage to main memory.

modify_item() − change value of item in the main memory.

write_item() − write the modified value from main memory to storage.

Database access is restricted to read_item() and write_item() operations. Likewise, for all transactions, read and write forms the basic database operations.

Transaction Operations

The operations at low levels conducted in a transaction are-

• begin_transaction-Start transaction is a marker that defines the start of the execution of the transaction.
• Read-item or write-item-Database operations that can be connected as part of the transaction with main memory operations.
• end_transaction − A marker that specifies the end of the transaction.
• Commit −A signal to specify that the whole transaction has been successfully completed and will not be reversed.
• Rollback-A signal to show that the transaction has been ineffective and thus all temporary modifications are undone in the database. A transaction committed can not be rolled back.

Transaction States

A transaction which move through an active, partially committed, committed, failed and aborted sub-set of five states.

• Active − The active state is the initial state in which the transaction enters. The transaction remains in this state when reading , writing or other operations are performed.
• Partially Committed -The transaction reaches this state after the last transaction statement has been executed.
• Committed-The transaction reaches this state after the transaction has been completed successfully and the commit signal has been provided by system control.
• Failed-When it is found that normal execution can no longer continue or system checks fail, the transaction goes from a partially committed state or active state to a failed state.
• Aborted-This is the state after the transaction was rolled back after failure and the database was returned to its state before the transaction started. This is the state.

Desirable Properties of Transactions

Any transaction must preserve the properties of ACID, viz. Atomicity, Consistency, Durability, and Isolation.

• Atomicity-This property states that a transaction is a processing atomic unit, that is, either it is carried out in its entirety or not carried out at all. There should be no partial updates.
• Consistency-The database can be taken from one consistent state to another consistent state by a transaction. Any data item in the database does not adversely affect it.
• Isolation-As if it is the only one in the system, a transaction should be executed. No interference from the other concurrent transactions that are operating at the same time should occur.
• Durability- If a committed transaction creates a change, the change in the database should be durable and not lost in the event of a failure.

Schedules and Conflicts

A schedule is the total order of execution of operations in a system with a number of simultaneous transactions. In view of the schedule S consisting of n transactions , i.e. T1, T2, T3 .......... Tn; for every Ti transaction, Ti transactions shall be executed as stated in schedule S.

There are two kinds of schedules:

Serial Schedules − In a serial schedule, only one transaction is active at any point of time, i.e. there is no transaction overlap. This is seen in the following graph –

Parallel Schedules-More than one transaction is active simultaneously in parallel schedules, i.e. the transactions involve transactions that overlap at the time. This is seen in the following graph –

A conflict occurs in a schedule consisting of several transactions when two active transactions execute non-compatible operations. If any of the following three conditions occur simultaneously, two operations are said to be in conflict.

• The two operations are components of various transactions.
• The same data item is accessed for both operations.
• A write item() operation is at least one of the operations , i.e. it attempts to change the data item.

Serializability

A 'n' transaction serializable schedule is a parallel schedule similar to a serial schedule containing the same 'n' transactions. A serializable schedule requires the correctness of the serial schedule when deciding that the parallel schedule is used best by the CPU.

Two schedules may be equivalent to the following types:

• Equivalence of results-Two schedules producing equal results are said to be equivalent to results.
• View equivalence is known to be view equivalent in two schedules that perform similar acts in a similar way.
• Conflict equivalence-Two schedules, if both contain the same set of transactions and have the same order of opposing pairs of operations, are said to be conflict equal.