What is Transaction Processing

In computer science, a transaction is a sequence of program steps that are regarded as a logical unit because they leave the data stock in a consistent state after error-free and complete execution. Therefore, a transaction is particularly required to be executed either completely and error-free or not at all.

Transactions are mostly used in database systems. Failed transactions must be canceled and the previous changes in the database reversed so that they do not affect the health of the database. Transactions are processed by transaction systems; these generate a history from several transactions.

Transactions are distinguished by the mark begin of transaction (abbreviation BOT) and end of transaction (abbreviation EOT):

When executing transactions, the transaction system must guarantee the ACID properties:

• Atomicity: A transaction is either executed completely or not at all. Transactions are therefore “indivisible”. If an atomic transaction is canceled, the system is unchanged.
• Consistency: After the transaction is executed, the data set must be in a consistent form if it was already in a consistent form at the beginning of the transaction.
• Isolation: If several transactions are executed at the same time, they must not influence each other.
• Durability: The effects of a transaction must persist in the database. This means that the effects of transactions must not be lost or fade over time. Strictly speaking, nesting transactions is not possible because of this property, since rolling back an external transaction would violate the permanence of an internal transaction that has already been executed.

The goal of a transaction system is always to process as many transactions as possible in the shortest possible time. The serial execution of transactions – i.e. the execution of transactions one after the other – is easy to implement, but often does not lead to optimal fulfillment of this performance criterion. Transaction systems therefore split transactions into their operations and assemble them into histories, while preserving the ACID properties.

There are two ways to end a transaction through this process:

• Commit: The transaction was completed successfully and without any problems, the impact of the transaction on the data set is permanently stored. The terms “commit” and “end of transaction” are often used interchangeably.
• Abort: Problems have occurred during the execution of the transaction, its execution will not continue. The condition of atomicity also requires that all effects of the transaction on the data set must be reversed.

Undoing the effects of a transaction is known as a rollback. It may happen that the resetting of one transaction requires the resetting of another transaction, which can lead to the formation of veritable chains of resets; this is called a cascading reset.

When a transaction cannot be executed due to another transaction, it is called a block. If the first transaction is blocked by the second and the second by the first, this is called a deadlock.

A nested transaction is a transaction that is completely enclosed by another transaction. The inner transaction sees the changes that are made by the outer one. There are several variants for the behavior of the two transactions.

Distributed transactions are transactions that occur in multiple sub-transactions in distributed systems. To ensure the atomicity of distributed transactions, appropriate commit protocols are used. An example is the execution of a transfer on the database system of the remittant’s bank and the database system of the recipient’s bank. If something goes wrong after the money transfer at the second bank (e.g. account number is invalid), the money must be automatically transferred back.