One of the most important functions of a transaction monitor is to coordinate with resource managers (the term “resource manager” is explained in section "X/Open conformance of openUTM"). Since openUTM supports the XA interface standardized by X/Open, it can interact with all resource managers that offer this interface, even if these are mixed within a transaction. More than one resource manager can be connected to a given UTM application at the same time.
Database systems play a central role among the resource managers. This section therefore concentrates on coordination with database systems. The database systems with which a UTM application is to interact are defined when generating the UTM application.
Supported database systems
openUTM (BS2000) supports coordination with the following database systems:
UDS/SQL
SESAM/SQL
Oracle
LEASY (from the point of view of openUTM, the LEASY file system behaves as a database system)
openUTM for Unix, Linux and Windows systems supports coordination with the following database system:
Oracle
Coordination between UTM transactions and database transactions
The data records stored in a database are subject to the locking and synchronization mechanisms of the respective database system, and not those of openUTM. To ensure global data consistency, UTM transactions must be synchronized with those of all database systems involved. For this purpose, openUTM uses the two-phase commit protocol. As soon as processing of a local transaction is complete, the transaction is initially switched to
the “preliminary end of transaction (PET)” state. The global end of transaction (commit) is not set until all the transactions involved have reached the PET state. Figure 2 illustrates this procedure by means of a simple example.
The UTM transaction and the database transactions can therefore be regarded as subsets of a global transaction. The global transaction cannot be terminated successfully until all of its subsets have been completed. If one of the subsets- either a UTM transaction or a database transaction - cannot be concluded, the global transaction is rolled back. This means that all changes made in the databases and the UTM storage areas by the transaction are reversed, and the asynchronous and output services called are canceled.
As far as the programmer is concerned, there is no additional effort involved in coordinating between openUTM and database systems.
Figure 2: Coordination between UTM and database transactions based on the two-phase commit protocol
Coordination with distributed and heterogeneous databases
All transaction systems support coordination with a resource manager, but only openUTM offers the following additional options:
A UTM application can coordinate with several database systems, i.e. a single UTM service program can contain calls to numerous database systems. In the context of distributed processing, data from several different database systems can be processed on a number of systems within the same transaction. openUTM thus supports secure interaction with distributed and heterogeneous databases on all conventional hardware and operating system platforms - even within the same service program.
Thanks to these features, openUTM is much more flexible than other transaction monitors: it allows you to integrate the existing data logistics into UTM applications without modification, and offers greater scope when extending the IT environment.
Error handling and diagnostics when coordinating with database systems
If errors occur when coordinating with database systems, openUTM performs all error handling procedures. There is no need for the programmer to take any special precautions.
The database system informs openUTM whether or not a call can be executed successfully. If an error occurs, openUTM checks the error level and reacts accordingly: it rolls back the transactions to the last synchronization point and outputs error messages containing information on the cause of the error.
To simplify diagnostics, an entry is created in an area of the UTM dump for each database call. A special tool is also provided for simple, precise analysis of the UTM dump.
Support for failover with Oracle Real Application Clusters
When working with Oracle Real Application Clusters, openUTM is able to resume the application run normally in case of a failover. Transactions interrupted by the failover are terminated correctly when possible. If this is not possible, then they are rolled back by openUTM or by the database system so that the database is also consistent after the failover.
Internal interface between openUTM and database systems
openUTM controls interaction with database systems via a standard, uniform interface. It is thus completely independent of any implementation-related specifications of the different database systems.
The interface used is the XA interface standardized by X/Open, and on BS2000 systems the functionally equivalent interface IUTMDB is supported.
Support for other resource managers
Database systems are only one type of resource manager. UTM transaction management also covers transaction-oriented file systems (e.g. LEASY), message queues, local storage areas, log files, and network connections. Regardless of whether the resource manager is a UTM resource manager (UTM message queues, local storage areas, log files) or an external resource manager (non-Siemens message queueing system), openUTM coordinates transaction management across all applications, operating Systems and hardware platforms.