Oracle Services for MTS in Oracle9i
Oracle9i provides Windows applications enhanced transactional support with the Oracle Services for Microsoft Transaction Server (MTS). The Oracle Services for MTS, or OraMTS, allow COM transactional deployment in COM+/MTS environments with the Oracle database.
At the core of MTS is the Distributed Transaction Coordinator (DTC), which coordinates transactions between distributed resource managers, such as the Oracle database. OraMTS acts as a proxy between the database and DTC to facilitate transaction coordination between the two. Specifically, OraMTS provides the following transactional features:
When a client application initiates a transaction request, MTS enlists the Oracle database to act as a resource manager (RM) in the transaction process. The focal point of the transaction process is Microsoft's DTC, which commits and aborts transactions using the two-phase commit protocol. Multiple DTCs can be involved in a single transaction. When the DTC commits or aborts a transaction, it sends the request to the Oracle database via OraMTS. Figure 1 provides more details on the Oracle9i OraMTS components involved in transaction coordination.
The graphic above demonstrates that the client, through it data access interfaces, requests the OraMTS integration layer to enlist a connection in a MTS transaction. The OraMTS integration layer exists within the MTS process. In previous OraMTS releases, this layer existed as a separate Windows service. This new design in Oracle9i improves performance as communication between MTS and OraMTS is now intra-process, rather than between processes.
Within the OraMTS integration layer a proxy cache exists for each database OraMTS uses as a resource manager. This allows each version of OraMTS to interact with Oracle databases independent of other OraMTS instances and other Oracle databases. In previous releases, one proxy existed to facilitate communication between all MTS servers and a database. This older architecture led to problems with availability and performance bottlenecks. In Oracle9i, high availability and performance in the middle-tier can be achieved because there is no single point of failure or bottleneck. Figure 2 demonstrates how the Oracle9i architecture can run multiple databases and multiple transaction servers with independent proxies so that no one database or server becomes a single point of failure for the entire system.
The database is responsible for initiating recovery to ensure that it occurs independent of the status of the MTS servers. A PL/SQL recovery job in the database periodically queries the DTC for any unresolved transactions. This PL/SQL job itself will survive database restarts. In recovery, the database requests the final outcome of in-doubt transactions from the DTC through a process called reenlistment.
DTC transaction recovery requires the use of COM. Since Oracle databases can run on operating systems that may not support COM, such as Solaris, an external process is required to resolve transaction outcomes with the DTC. On each MTS server, Oracle has a single recovery daemon instance which services in-doubt transaction resolution requests for transactions originating from that server. The database PL/SQL recovery job contacts the MTS server recovery daemon to resolve any in-doubt transactions that originated from that server. The recovery daemon in turn contacts its DTC to resolve the transaction and conveys the outcome to the PL/SQL recovery job. The PL/SQL job then commits or aborts the in-doubt transaction in the database.
OraMTS allows developing applications with a variety of data access interfaces, including OO4O, OCI, ADO/OLE DB, and ODBC. In general, OO4O and OCI provide better performance and compatibility with Oracle. OO4O and OCI use connection pooling provided by Oracle's resource dispensers. The Oracle Provider for OLE DB and the Oracle ODBC driver employ Microsoft resource management for database connections. Although OraMTS's design has changed in Oracle9i, application developers will not need to change any of their application or data access code to use the new architecture. For MTS administrators, the new OraMTS design has made administration and configuration easier because OraMTS automatically configures itself on the MTS server.
The new Oracle9i OraMTS has many benefits over the previous versions:
500 Oracle Parkway
Redwood Shores, CA 94065
© Oracle Corporation 2001
All Rights Reserved
This document is provided for informational purposes only, and the information herein is subject to change without notice. Please report any errors herein to Oracle Corporation. Oracle Corporation does not provide any warranties covering and specifically disclaims any liability in connection with this document.
Oracle, Oracle9i, and PL/SQL are a trademarks of Oracle Corporation.
All other company and product names mentioned are used for identification purposes only and may be trademarks of their respective owners.