Oracle Services for MTS in Oracle9i

Features Overview

October 2001



Product Summary

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:

  • Enlistment - Context maintenance for global transactions
  • Completion - Translation of two-phase commit calls between DTC and Oracle
  • Recovery - Resolution of in-doubt DTC transactions
  • Connection pooling - Caching of transactional database connection resources to improve performance
OraMTS can be utilized from any Windows programming language through Oracle's data access drivers. These data access drivers include ODBC, ADO/OLE DB, Oracle Objects for OLE (OO4O), and OCI. OraMTS is part of the Oracle9i client software and is supported for use against Oracle9i, Oracle8i, and Oracle8 database servers. It is not necessary for the database server to be on Windows in order to inter-operate with OraMTS. Although OraMTS is required to be on Windows, the database can run on UNIX, while communicating transparently with OraMTS.

Components and Architecture

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.

Oracle9i Enhancements

The new Oracle9i OraMTS has many benefits over the previous versions:

  • Higher Availability - The database server is no longer dependent on a single OraMTS proxy to communicate with the middle-tier. Previously, if the OraMTS server stopped, whether it be a hardware or software failure, the database server would be unable to participate in MTS transactions due to the reliance on the single OraMTS proxy. In the new architecture, each OraMTS instance manages its own proxy or proxies. So, if an OraMTS server were to fail, it would not prevent other OraMTS servers from communicating with the database.
  • Improved Scalability - Having a single proxy in older OraMTS versions led to the possiblility of creating a bottleneck for transactional applications. If the server with the proxy had slow performance, all other OraMTS servers would experience slow performance also. With independent proxies in Oracle9i, no single OraMTS proxy acts as a bottleneck for other servers.
  • Better Performance - Because OraMTS runs within the MTS server process, communication between the two occurs much faster than before. In previous versions, OraMTS ran as a separate Windows service outside of MTS. Extra-process communication is generally slower than intra-process communications. Thus, Oracle9i users will gain a performance boost in their transactional applications.
  • Simpler Configuration With Oracle9i, manual MTS server configuration with OraMTS is eliminated; configuration is handled automatically by OraMTS upon installation. To configure the database for OraMTS, all that is required is for a script to be run, which sets up OraMTS user accounts and the transaction recovery job.
There is some configuration necessary when moving from an older OraMTS version to the Oracle9i version. For more information on how to upgrade from an older OraMTS version, please view the associated documentation.





Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065

Worldwide Inquiries:
Fax +1.650.506.7200

Copyright © 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.