UTM services process jobs in transaction-oriented mode, i.e. an openUTM service consists of one or more transactions. If an openUTM service communicates with another application via OSI TP, it is possible to define whether processing in the remote application is to be included in the transaction or takes place independently of the transaction. The former case involves a distributed transaction, while the latter case involves independent transactions. Distributed transactions are always used when working with the LU6.1 protocol.
Distributed transactions
During server-to-server communication, several local transactions in various applications are involved in processing a job. In the case of global (= cross-application) transaction management, openUTM guarantees global data consistency at all times. For this purpose, openUTM synchronizes the end of the transaction: if the transaction is completed successfully, the synchronization points are set simultaneously in all applications involved. In the event of an error, openUTM ensures that all transactions affected are rolled back. The synchronized transactions thus form a unit, known as a “distributed transaction”. For synchronization purposes, openUTM uses the two-phase commit protocol: as soon as processing of a local transaction is complete, the transaction is initially switched to the “Prepare-to-Commit” state. The global end of transaction (commit) is not set until all the transactions involved have reached the “Prepare-to-Commit” state. An example of this can be found in section “Example: Global dialog with a distributed transaction”.
Asynchronous jobs (MQ jobs) are transferred only once during server-to-server communication with global transaction management. This means that asynchronous jobs are neither lost, nor duplicated even after a power failure or an application crash.
Global transaction management is required in cases whether data consistency and data security requirements are high.
Independent transactions
Unlike distributed transactions, each application is responsible for comitting and rolling back their own independent transactions. In the event of communication errors, this may result in data inconsistencies in the various applications. With this form of communication, there is no guarantee that asynchronous jobs will not be duplicated.
This type of interaction between applications is useful for cases where the data of only one application is modified during processing. For example, this applies if one of the applications is a pure retrieval application. Communication is thus more efficient, since the transactions need not be synchronized in the applications involved.