One of the most important tasks of openUTM is to ensure the consistency and integrity of application data, even in the event of problems such as power failures or system crashes. All processes under openUTM are therefore based on the transaction concept.
A transaction is a collection of operational steps with certain properties, known as ACID properties:
Atomicity
The steps combined within a transaction form an atomic unit: either all the steps within the transaction are performed, or none of them are performed (all-or-nothing rule). If a transaction is not executed in full for some reason, it is rolled back, i.e. all data is reset to its status before the transaction was started.Consistency
The individual steps are performed correctly. If the resources (databases, printers, message queues, etc.) were in an inconsistent state before the transaction was started, they will be restored to a consistent state after the transaction has ended.Isolation
If several transactions are to be executed in parallel, concurrent changes are carried out as if the transactions were executed consecutively, i.e. with no overlap. Other transactions are not aware of any intermediate states, as the transactions are isolated from each other.Durability
Once a transaction has been concluded successfully, the changes made are permanent, i.e. they are retained even after a system crash. All modifications are logged at the end of the transaction. The end of a transaction therefore also represents a synchronization point.
For example, a credit transfer consisting of the steps “debit amount” and “credit amount” fulfills the atomicity condition provided each debit operation is followed by a credit operation. It fulfills the consistency condition if the amount is debited and credited in the prescribed format and at the right location. It fulfills the isolation condition if the account balances are read-/write-protected during processing. Finally, it fulfills the durability condition if the updates are not lost following a system error, e.g. due to a power failure.
openUTM fully integrates all resources into transaction management, and can thus offer effective automatic restart functions.
In the event of an automatic restart, openUTM resynchronizes not only the data in the databases with the data in the application, but also any interrupted services, local resources (e.g. storage areas), queues, communication links, and front-ends such as terminals, PCs, workstations, and printers.
For instance, the restart functionality allows all client PCs to continue operating with the last consistent PC screen, even after a system crash (PCs, network, server).
| You will find additional information on the subject of “restarts” in this manual in section "The openUTM restart functions". |
