Oracle xa driver

The developer, when using a DataSource to do local transaction work, must commit and close the connection rolling back if any exceptions occur.

This is because, if an XA transaction is started afterwards, the connection will still be in a 'local' mode, and the XA driver may not accept being in local mode. The platform detects that no XA transaction is active, and will handle things such that there is no extra overhead such as unrequired XA-related calls. This section includes examples of config. Note: These are only partial config. They are not complete config. This section includes partial config. DataSource API, but not through the deprecated java.

DriverManager or java. Driver API. Attempting to enable autocommit mode by calling the java. Using Precompilers with the Default Database. Using Precompilers with a Named Database. The absence of this field indicates the default connection.

Only one default connection is allowed for each process. An application might include the default database and one or more named databases. For example, suppose you want to update an employee's salary in one database, his department number DEPTNO in another, and his manager in a third database.

Configure the open strings in the transaction manager as shown in Example Again, the default connection corresponding to the third open string that does not contain the DB field needs no declaration.

There is no AT clause in the last statement because it is referring to the default database. In Oracle Database precompilers release 1. Work performed on non-XA connections is outside the global transaction and must be committed separately. Rather, the logon must be done through the TPM. The applications can run the function xaoSvcCtx to obtain the service context structure when they must access the resource manager. In applications that must pass the environment handle to OCI functions, you can also call xaoEnv to find that handle.

Because an application server can have multiple concurrent open Oracle Database resource managers, it must call the function xaoSvcCtx with the correct arguments to obtain the correct service context.

Oracle Call Interface Programmer's Guide. When you use the XA library, transactions are not controlled by the SQL statements that commit or roll back transactions. The TMs typically control the transactions through the XA interface.

This interface includes the functions described in Table A service is a logical unit of work that, for Oracle Database as the resource manager, comprises a set of SQL statements that perform a related unit of work.

For example, when a service named "credit" receives an account number and the amount to be credited, it runs SQL statements to update information in certain tables in the database. Also, a service might request other services. For example, a "transfer fund" service might request services from a "credit" and "debit" service. Typically, application clients request services from the application servers to perform tasks within a transaction.

For some TPM systems, however, the application client itself can offer its own local services. As shown in " Examples of Precompiler Applications " , you can encode transaction control statements within either the client or the server. To have multiple processes participating in the same transaction, the TPM provides a communication API that enables transaction information to flow between the participating processes.

At least one of these alternatives is supported by each of the leading TPM vendors. These examples illustrate precompiler applications.

Example shows a transaction started by an application server. Example shows a transaction started by an application client. If you do not specify the SqlNet parameter in your open string, then the application uses the default Oracle Net driver.

This is accomplished in a TPM-specific fashion. See your TPM vendor documentation for instructions on how to accomplish this. The preceding is true only for global rather than local transactions. Commit or roll back local transactions with the Oracle API. If you use a transaction monitor that supports threads, then the Oracle XA library enables you to write applications that are thread-safe.

Nevertheless, keep certain issues in mind. A thread of control or thread refers to the set of connections to resource managers. In an nonthreaded system, each process is considered a thread of control because each process has its own set of connections to RMs and maintains its own independent resource manager table. In a threaded system, each thread has an autonomous set of connections to RMs and each thread maintains a private RM table. This private table must be allocated for each thread and deallocated when the thread terminates, even if the termination is abnormal.

Specifying Threading in the Open String. Restrictions on Threading in Oracle XA. You must specify this clause as true to enable the use of threads by the TM. The default is false. In most cases, the TM creates the threads; the application does not know when a thread is created. Therefore, it is advisable to allocate a service context on the stack within each service that is written for a TM application.

Before doing any Oracle Database-related calls in that service, you must call the xaoSvcCtx function to retrieve the initialized OCI service context. You can then use this context for OCI calls within the service. This is typically accomplished by using a special C compiler provided by the TM vendor.

Therefore, when threading is enabled, you cannot use embedded SQL statements across non-XA connections. If one thread in a process connects to Oracle Database through XA, then all other threads in the process that connect to Oracle Database must also connect through XA.

All three sessions are connected to the HR schema. The Oracle XA library logs any error and tracing information to its trace file. This information is useful in supplementing the XA error codes. Its DB field was not specified in the open string when the resource manager was opened. Its DB field was specified as "Finance" in the open string when the resource manager was opened. Multiple Oracle XA library resource managers with the same DB field and LogDir field in their open strings log all trace information that occurs on the same day to the same trace file.

Table explains the meaning of each element. Normally, the XA trace file is opened only if an error is detected. By default, its value is zero.

You can set it to any combination of these values:. This value can be useful in seeing exactly which XA calls the TP Monitor is making and which transaction identifier it is generating. This is generally useful only to Oracle Database developers. The flags are independent bits of an ub4 , so to obtain printout from two or more flags, you must set a combined value of the flags.

If you do not specify LogDir in the open string, then the Oracle XA application attempts to create the trace file in this directory if the Oracle home is accessible :. If the Oracle XA application cannot determine where the Oracle home is located, then the application creates the trace file in the current working directory.

In-doubt or pending transactions are transactions that were prepared but not committed to the database. In general, the TM provided by the TPM system resolves any failure and recovery of in-doubt or pending transactions. The DBA might have to override an in-doubt transaction if these situations occur:. See the TPM documentation for more information about overriding in-doubt transactions in such circumstances and about how to decide whether to commit or roll back the in-doubt transaction.

If you do not specify this field in the open string, then the value of this column is NULLxa. For example, this SQL statement provide more information about in-doubt transactions generated by Oracle XA applications:.

Oracle XA applications can access other Oracle Database instances through database links with these restrictions:. Then the operating system network connection required for the database link is opened by the dispatcher instead of a dedicated server process.

This allows different services or threads to operate on the transaction. If this restriction is not satisfied, then when you use database links within an XA transaction, it creates an operating system network connection between the dedicated server process and the other Oracle Database B.

Because this network connection cannot be moved from one dedicated server process to another, you cannot detach from this dedicated server process of database A. Then when you access the database B through a database link, you receive an ORA error. If these restrictions are satisfied, Oracle Database allows such links and propagates the transaction protocol prepare, rollback, and commit to the other Oracle Database instances. The init. These dblink connections are used by XA transactions so that the connections are cached after a transaction is committed.

Another transaction can use the database link connection if the user who created the connection also created the transaction. This parameter is different from the init. If the transaction branches are tightly coupled , then they share locks. Consequently, pre- COMMIT updates in one transaction branch are visible in other branches that belong to the same global transaction. In loosely coupled transaction branches, the branches do not share locks and do not see updates in other branches.

In a tightly coupled branch, Oracle Database obtains the DX lock before running any statement. Because the system does not obtain a lock before running the statement, loosely coupled transaction branches result in greater concurrency. The disadvantage is that all transaction branches must go through the two phases of commit, that is, the system cannot use XA one-phase optimization.

Table summarizes the trade-offs between tightly coupled branches and loosely coupled branches. As of Oracle Database 11 g Release 1 Its default value is 1. Leave this parameter at its default value clusterwide if distributed transactions might span multiple Oracle RAC instances. This allows the units of work performed across these Oracle RAC instances to share resources and act as a single transaction that is, the units of work are tightly coupled.

It also allows 2PC requests to be sent to any node in the cluster. Oracle Database permits different instances to operate on different transaction branches in Oracle RAC. For example, Node 1 can operate on branch A while Node 2 operates on branch B.

Before Oracle Database 11 g Release 1 In this case, Oracle Database treated different units of work in different application threads as separate entities that did not share resources.

A different case is when multiple instances operate on a single transaction branch. Prior to Adaptive Server version The server could not share a transaction with any task other than the one that initiated the transaction. Adaptive Server version Transactions can be shared among different execution threads, or may not be associated with an execution thread detached. On the Sybase server, you can set the dtm detach timeout period , which sets the amount of time in minutes that a distributed transaction branch can remain in the detached state without an associated execution thread.

After this period, the DBMS automatically rolls back the transaction. The dtm detach timeout period applies to all transactions on the database server. It cannot be set for each transaction. For example, to automatically rollback transactions after being detached for 10 minutes, use the following command:. You should set the dtm detach timeout period higher than the transaction timeout to prevent the database server from rolling back the transaction before the transaction times out in WebLogic Server.

For more information about the dtm detach timeout period , see the Sybase documentation. If a global transaction is started on the Sybase server, but is not completed, the outcome of the transaction varies depending on the transaction state before the transaction is abandoned:. This issue is fixed in version 9. REAL 2. Fixed in 9. Log on to sqlplus as system user, e.

Execute the following command: xaview. In case of multiple connection-pooled configurations, each connection pool should have separate database instance. A transaction cannot be initiated with a resource that is already associated with a suspended transaction. In this case, a javax. InvalidTransactionException attempt to resume an inactive transaction is thrown. If in between suspend and resume , an intermediate transaction enlists the same resource as used in the suspended transaction, a javax.

If a different resource is used inside the intermediate transaction, it works fine. Vendor fix required. Vendor fix has been requested.