Distributed processing with global transaction management can be done via the LU6.1 or OSI TP protocols. openUTM always works with global transaction management for LU6.1 while global transaction management is only valid for OSI TP if the “Commit” function unit is selected.
Rolling back distributed transactions
There are a number of reasons why openUTM will roll back a distributed transaction, e.g. violation of programming rules, loss of connection, timeout when monitoring response times, termination of an application, or in certain situations after the failover of a database with open transactions, see "Coordinating with databases and resource managers" as well.
Depending on the reason for the roll-back, either the job-submitting and/or the job-receiving services are terminated because resumption was not possible or practical, or the jobsubmitting and the job-receiving service are rolled back to the last synchronization point and communication is restarted (service restart).
| Detailed information on this can be found in the openUTM manual „Programming Applications with KDCS”. |
Loss of connection
The connection between two applications may be lost if errors occur on the communication link, or if one of the two applications is terminated. Loss of the connection between the partners causes the transaction to be rolled back.
When communicating via the OSI TP protocol, the job-receiving service is terminated when the connection is lost. When using the LU6.1 protocol, the job-receiving service is terminated only if it has not yet reach a synchronization point.
If the job-receiving service is terminated, the job-submitting service receives an error message.
If the job-submitting service has not yet reached a synchronization point, it too is terminated. If this occurs, it obviously does not receive any further error messages. However, openUTM sends a message to the terminal or the client program that started the jobsubmitting service.
Restarting interrupted services
If the global transaction is rolled back (e.g. due to a loss of connection, timeout, or termination of the application) without terminating the job-submitting service, a service restart is performed. In this case, communication between the client and the job-submitting service and (when using LU6.1) between the job-submitting service and the job-receiving service is resumed from the last synchronization point.
The restart takes place immediately if the client is still connected to the job-submitting application. If the client is no longer connected to the job-submitting application after the rollback procedure, e.g. because the connection to the client was shut down, the restart takes place as soon as the client signs back on to the application.
Restarting a session (only for communication via LU6.1)
A “session” is the communication relationship between applications based on the LU6.1 protocol. Each transport connection between the applications is assigned to a session. If communication is interrupted, the session concept allows you to save information on the last message sent and logged. Communication can thus be resumed at this point.
After a connection is lost, openUTM automatically attempts to restart communication at a synchronization point. A transport connection must be available for this purpose.
A session can be restarted by:
the automatic resumption of communication when the job-submitting and the jobreceiving services are restarted
the restart of an application, if automatic connection setup is generated for the remote application
an administration command
resending a message via the session
A session restart may be rejected by the remote partner if the partner is not in a position to process the restart at that time. In this case, the partner can reinitiate the session restart at a later point in time.