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.