XA Issues and Restrictions

For example, you could use the following SQL statement to obtain more information about in-doubt transactions generated by Oracle XA applications.

SELECT * FROM Dba_2pc_pending p, Dba_2pc_neighbors n WHERE p.Local_tran_id = n.Local_tran_id

AND

n.Dbid = 'xa_orcl';

Alternatively, if you know the format ID used by the transaction processing monitor, then you can use DBA_PENDING_TRANSACTIONS or V$GLOBAL_ TRANSACTIONS. While DBA_PENDING_TRANSACTIONS gives a list of both active and failed prepared transactions, V$GLOBAL_TRANSACTIONS gives a list of all active global transactions.

XA Issues and Restrictions

Database Links

Oracle XA applications can access other Oracle Database instances through database links, with the following restrictions:

■Use the shared server (formerly known as Multi-Threaded Server) configuration.

This means that the transaction processing monitors (TPMs) use shared servers to open the connection to Oracle Database. The operating system network connection required for the database link is opened by the dispatcher, instead of the Oracle Database process. Thus, when a particular service or RPC completes, the transaction can be detached from the server so that it can be used by other services or RPCs.

■Access to the other database must use SQL*Net Version 2, Net8, or Oracle Net.

(SQL*Net and Net8 are former names of Oracle Net.)

■The other database being accessed should be another Oracle Database instance.

Assuming that these restrictions are satisfied, Oracle Database allows such links and propagates the transaction protocol (prepare, rollback, and commit) to the other Oracle Database instances.

Using Oracle XA with Transaction Monitors 16-27

XA Issues and Restrictions

Caution: If these restrictions are not satisfied, then when you use database links within an XA transaction, it creates an O/S network connection in the Oracle Database instance that is connected to the TPM server process. Because this O/S network connection cannot be moved from one process to another, you cannot detach from this server. When you access a database through a database link, you receive an ORA#24777 error.

If using the shared server configuration is not possible, then access the remote database through the Pro*C/C++ application using EXEC SQL AT syntax.

The parameter open_links_per_instance specifies the number of migratable open database link connections. These dblink connections are used by XA transactions so that the connections are cached after a transaction is committed. Another transaction is free to use the dblink connection provided the user that created the connection is the same as the user who created the transaction. This parameter is different from the open_links parameter, which is the number of dblink connections from a session. The open_links parameter is not applicable to XA applications.

Oracle Real Application Clusters

You can recover failed transactions from any instance of Oracle Real Application Clusters. You can also heuristically commit in-doubt transactions from any instance. An XA recover call gives a list of all prepared transactions for all instances.

A sequence of operations like the following must be performed on the same instance:

1.xa_start

2.xa_commit

3.SQL operations

4.xa_end

5.xs_prepare

6.xa_commit or xs_rollback

Under normal circumstances, an xa_prepare, xa_rollback, or xa_commit operation performed on a branch must be performed on the same instance that created the branch. This restriction affects load balancing. If load balancing is enabled, it is possible for sequences like the following to be performed on two

16-28 Oracle Database Application Developer's Guide - Fundamentals

XA Issues and Restrictions

different nodes. For this reason, load balancing must not be used for the XA connection.

Node 1

1.xa_start

2.SQL operations

3.xa_end(SUSPEND)

Node 2

1.xa_start(RESUME)

2.SQL operations

3.xa_end

If an error occurs, xa_recover must be performed before any other XA operations. You should open the XA connection with xa_open using option RAC_ FAILOVER=true.

Note: The operation xa_recover cannot be used for switchover in normal operation.

Global uniqueness of transaction IDs (XIDs) is not guaranteed; the TM must maintain the global uniqueness of XIDs. According to the XA specification, the RM must accept XIDs from the TM. However, XA on RAC cannot determine if a given XID is unique throughout the cluster.

Suppose, for example, there is a Tx(1).Br(1) on Node 1, and another Tx(1).Br(1) on Node 2. Each of these can start and execute SQL, even though the XID is not unique.

See Also: X/OPEN CAE Specification Distributed Transaction Processing: The XA Specification, ISBN 1 872630 24 3, XOPEN Document Number XO/CAE/91/300

SQL-Based Restrictions

Rollbacks and Commits

Because the transaction manager is responsible for coordinating and monitoring the progress of the global transaction, the application should not contain any Oracle

Using Oracle XA with Transaction Monitors 16-29

XA Issues and Restrictions

Database-specific statement that independently rolls back or commits a global transaction. However, you can use rollbacks and commits in a local transaction.

Do not use EXEC SQL ROLLBACK WORK for precompiler applications when you are in the middle of a global transaction. Similarly, an OCI application should not execute OCITransRollback(), or the Version 7 equivalent orol(). You can roll back a global transaction by calling tx_rollback().

Similarly, a precompiler application should not have the EXEC SQL COMMIT WORK statement in the middle of a global transaction. An OCI application should not execute OCITransCommit() or the Version 7 equivalent ocom(). Instead, use tx_ commit() or tx_rollback() to end a global transaction.

DDL Statements

Because a DDL SQL statement, such as CREATE TABLE, implies an implicit commit, the Oracle XA application cannot execute any DDL SQL statements.

Session State

Oracle Database does not guarantee that session state will be valid between services. For example, if a service updates a session variable (such as a global package variable), then another service that executes as part of the same global transaction may not see the change. Use savepoints only within a service. The application must not refer to a savepoint that was created in another service. Similarly, an application must not attempt to fetch from a cursor that was executed in another service.

SET TRANSACTION

Do not use the SET TRANSACTION READ ONLY | READ WRITE | USE ROLLBACK SEGMENT SQL statement.

Connecting or Disconnecting with EXEC SQL

Do not use the EXEC SQL command to connect or disconnect. That is, do not use

EXEC SQL COMMIT WORK RELEASE or EXEC SQL ROLLBACK WORK RELEASE.

Transaction Branches

Oracle Database transaction branches within the same global transaction can be coupled tightly or loosely. If they are tightly coupled, then they share locks. However, if the branches are on different instances when running Oracle Real Application Clusters, then they are loosely coupled, and they do not share locks.

16-30 Oracle Database Application Developer's Guide - Fundamentals

XA Issues and Restrictions

In tightly coupled transaction branches, the locks are shared between the transaction branches. This means that updates performed in one transaction branch can be seen in other branches that belong to the same global transaction before the update is committed. Oracle Database obtains the DX lock before executing any statement in a tightly coupled branch. Hence, the advantage of using loosely coupled transaction branches is that there is more concurrency (because a lock is not obtained before the statement is executed). The disadvantage is that all the transaction branches must go through the two phases of commit, that is, XA one phase optimization cannot be used. These trade-offs between tightly coupled branches and loosely coupled branches are described in Table 16–4.

Table 16–4 Tightly and Loosely Coupled Transaction Branches

Association Migration

Oracle Database does not support association migration (a means whereby a transaction manager may resume a suspended branch association in another branch).

Asynchronous Calls

The optional XA feature asynchronous XA calls is not supported.

Initialization Parameters

Set the transactions init.ora parameter to the expected number of concurrent global transactions.

The parameter open_links_per_instance specifies the number of migratable open database link connections. These dblink connections are used by XA transactions so that the connections are cached after a transaction is committed.

See Also: "Database Links" on page 16-27

Maximum Connections for Each Thread

The maximum number of xa_opens for each thread is 32.

Using Oracle XA with Transaction Monitors 16-31