Transaction (computer science)

As a transaction (from Latin trans "(over) over", agere "drive, act, lead": literally: transfer; dt. Here better: execution ) is a sequence of program steps in computer science , which as a logical unit be considered because they leave the database in a consistent state after it has been executed correctly and completely. A transaction is therefore particularly required to be carried out either completely and without errors or not at all.

Transactions are mostly used in database systems . Incorrect transactions must be aborted and the previous changes in the database reversed so that they have no effect on the state of the database. Transactions are processed by transaction systems; these generate a history from several transactions .

example

In order to be able to clearly imagine the most important terms of this article, the following example should serve:

In a library an index card system is used to manage the inventory of books. A transaction here could be: "Lend the book 'Die Schatzinsel' to the user Peter Müller." The formal representation of this transaction could look like this:

Beginning of the transaction

read the "pre-order" field on the card

Write “Peter Müller” in the “Borrowed from” field

"29. July 2001 ”in the“ Return on ”field

End of transaction

If the card was successfully filled in, the transaction is completed and the card is inserted back into the card box - this corresponds to the commit of a transaction. If the execution was interrupted, all changes made up to that point must be undone before the card is inserted back - this corresponds to the abortion of a transaction. If this is not done, errors can occur: If, for example, "Borrowed from" has already been filled in, but the return date has not yet been entered, Peter Müller can enjoy "Treasure Island" until the end of his life without having to fear penalties. For example, a conflict between transactions would arise if the book were to be loaned to another user at the same time; here the property “isolation” would be violated.

Structure of transactions

Transactions are delimited by the markings begin of transaction (abbreviation BOT ) and end of transaction (abbreviation EOT , see Commit ):

begin of transaction
   read x
   write y
end of transaction

The operations within a transaction are ordered , so their order must not be changed. The order of the operations of a transaction can also be represented as a directed graph :

{\ displaystyle {\ begin {matrix} r [x] & \ rightarrow & w [x] & \ rightarrow & r [y] & \ rightarrow & c \\ &&& \ nearrow \\ && r [z] \ end {matrix}}}

This representation emphasizes the concurrency - i.e. the simultaneous executability - of operations. In the above example, the operation r [z] can be carried out simultaneously with the operations r [x] and w [x].

ACID principle

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

Atomicity ( A tomicity): A transaction is either executed completely or not. Transactions are therefore "indivisible". If an atomic transaction is aborted, the system is unchanged.
Consistency ( C onsistency): After execution of the transaction, the database must be in a consistent form when he was at the beginning of the transaction.
Insulation ( I solation): Co-execution of multiple transactions, they must not influence each other.
Durability ( D urability): The effects of a transaction must remain permanently in the database. The effects of transactions must not be lost or fade over time. Strictly speaking, this property does not allow transactions to be nested, since a rollback of an external transaction would violate the durability of an internal transaction that has already been executed.

Execution of transactions in a transaction system

The aim 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 the transactions one after the other - is easy to implement, but often does not lead to an optimal fulfillment of this performance criterion. Transaction systems therefore split transactions into their operations and put them together into histories , whereby the ACID properties must be preserved.

This process gives two ways to end a transaction:

Commit (complete, abbrev. C ): The transaction was completed successfully and without problems, the effects of the transaction on the database are saved permanently. The terms “commit” and “end of transaction” are often used synonymously.
Abort (abort, abbr. A ): Problems occurred while executing the transaction and will not continue. The condition of atomicity also requires that all effects of the transaction on the database must be reversed.

The undo the effects of a transaction is referred to as rollback (Reset) , respectively. It can happen that rolling back one transaction makes rolling back another transaction necessary, which can lead to the formation of real chains of rollbacks; this is known as a cascading reset .

If a transaction cannot be carried out due to another transaction, it is called a blocking . If the first transaction blocked by the second, while the second through the first, it is called a deadlock ( jamming ).

Nested transactions

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

If the transactions are flat , aborting the inner transaction also aborts the outer transaction. The changes to the inner transaction are not valid if the outer transaction does not complete successfully.

If the transactions are closed , an abortion of the inner transaction does not automatically lead to an abortion of the outer transaction. If the inner transaction completes its actions successfully, the changes made are only visible to the outer transaction. The change is only visible to the entire system when the outermost transaction is successfully terminated.

In contrast, in the case of open transactions, the change in the inner transaction is immediately visible in the entire system after its termination. These changes persist even if the outer transaction is later canceled.

Distributed Transactions

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

Ineffective transactions

A transaction within a schedule is considered ineffective if it meets one of the following conditions:

only read operations are carried out
only write operations are carried out and the written values are overwritten again by other transactions without being read out in the meantime.

Ineffective means that the transactions had no effect on the database. Ineffective transactions therefore do not have to be rolled back in the event of a rollback.