Using WebLogic jDriver for Oracle/XA in Distributed Transactions


	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	e-docs \| Site Map \| Search \| Contact \| Glossary \| WebLogic Server Documentation

Installing and Using WebLogic jDriver for Oracle: Previous topic \| Next topic \| Contents

The following sections describe how to integrate transactions with EJB and RMI applications that use the WebLogic jDriver for Oracle/XA and run under BEA WebLogic Server.

Differences Using the WebLogic jDriver for Oracle in XA versus Non-XA Mode

Weblogic jDriver for Oracle supports fully the JDBC 2.0 Optional Package API for distributed transactions. Applications using the driver in distribution transaction (XA) mode can use all JDBC 2.0 Core API the same way as in local distribution (non-XA mode), with the exception of the following:

Connections have to be obtained via the JDBC 2.0 javax.sql.DataSource API, but not through the deprecated java.sql.DriverManager or java.sql.Driver API.
When used in Weblogic Server, this means you have to configure a TxDataSource in order to use it. Refer to "Managing JDBC Connectivity" in the Administration Guide for instructions about configuring TxDataSource and Connection Pools.
Auto commit is false by default. Attempting to enabled autocommit mode by calling the java.sql.Connection.setAutoCommit method on the Connection will throw a SQLException.
Attempting to complete the distributed transaction by calling java.sql.Connection.commit or java.sql.Connection.rollback methods will throw a SQLException.

The reason for the last two differences is because when the WebLogic jDriver for Oracle/XA participates in a distributed transaction, it is the external Transaction Manager that is demarcating and coordinating the distributed transaction.

For more information, refer to JDBC 2.0 Standard Extension API spec [version 1.0, dated 98/12/7 Section 7.1 last 2 paragraphs] for more detailed explanation.

Configuring JDBC XA and Non-XA Resources

You use the Administration Console to configure your JDBC resources, as described in the following sections.

JDBC/XA Resources

To allow XA JDBC drivers to participate in distributed transactions, configure the JDBC connection pool as follows:

Specify the DriverName property as the name of the class supporting the javax.sql.XADataSource interface.
Ensure that the database properties are specified. For more information on data source properties for the WebLogic jDriver for Oracle, see the Administration Guide. For information on data source properties for third-party drivers, see the vendor's documentation.

See the Administration Console Online Help on the JDBC Connection Pools panel for procedures and attribute definitions.

Non-XA JDBC Resources

To support non-XA JDBC resources:

Select the enableTwoPhaseCommit database property when configuring a JDBC Tx Data Source. For more information on this property, see the Administration Guide.

Limitations of the WebLogic jDriver for Oracle XA

Weblogic jDriver for Oracle in XA mode does not support the following:

Mixing local and global transactions. This throws a SQLException if an SQL operation is attempted with no global transaction.
Keeping result sets open across multiple remote calls into the same method, or across a call to another remote object. This action closes all result sets implicitly whenever the XA resource is delisted. This limitation is due to a bug in Oracle 8.1.6 OCI client libraries when used with XA.
Performing DDL operations (e.g. create/drop table, stored procedures etc). If you want to perform DDL operations, you need to define two different connection pools as follows:
- One non-XA connection pool that can be used for DDL operations.
- One XA connection pool that can be used for DML operations in distributed transactions.

Implementing Distributed Transactions

This topic includes the following sections:

Importing Packages

Listing 4-1 shows the packages that the application imports. In particular, note that:

The java.sql.* and javax.sql.* packages are required for database operations.
The javax.naming.* package is required for performing a JNDI lookup on the pool name, which is passed in as a command-line parameter upon server startup. The pool name must be registered on that server group.
Listing 4-1 Importing Required Packages
```
import java.sql.*;
import javax.sql.*;
import javax.naming.*;
```

Finding the Data Source via JNDI

Listing 4-2 shows finding the data source via JNDI.

Listing 4-2 Finding the Data Source via JNDI

static DataSource pool;

...

public void get_connpool(String pool_name)
    throws Exception
  {
    try {
      javax.naming.Context ctx = new InitialContext();
      pool = (DataSource)ctx.lookup("jdbc/" + pool_name);
    }
    catch (javax.naming.NamingException ex){
      TP.userlog("Couldn't obtain JDBC connection pool: " + pool_name);
      throw ex;
    }
  }
}

Performing a Distributed Transaction

Listing 4-3 shows a distributed transaction involving two database connections and implemented as a business method within a session bean.

Listing 4-3 Performing a Distributed Transaction

public class myEJB implements SessionBean {
     EJBContext ejbContext;

     public void myMethod(...) {
          javax,transaction.UserTransaction usertx;
          javax.sql.DataSource data1;
          javax.sql.DataSource data2;
          java.sql.Connection conn1;
          java.sql.Connection conn2;
          java.sql.Statement stat1;
          java.sql.Statement stat2;

          InitialContext initCtx = new InitialContext();
          
          // 
          // Initialize a user transaction object.
          // 
          usertx = ejbContext.getUserTransaction();
          
          //Start a new user transaction.
          usertx.begin();
          
          // Establish a connection with the first database
          // and prepare it for handling a transaction. 
          data1 = (javax.sql.DataSource)
               initCtx.lookup("java:comp/env/jdbc/DataBase1");
          conn1 = data1.getConnection();
          
          stat1 = conn1.getStatement();
          
          // Establish a connection with the second database
          // and prepare it for handling a transaction. 
          data2 = (javax.sql.DataSource)
               initCtx.lookup("java:comp/env/jdbc/DataBase2");
          conn2 = data1.getConnection();
          
          stat2 = conn2.getStatement();
          
          //Update both conn1 and conn2. The EJB Container
          //automatically enlists the participating resources.
          stat1.executeQuery(...);
          stat1.executeUpdate(...);
          stat2.executeQuery(...);
          stat2.executeUpdate(...);
          stat1.executeUpdate(...);
          stat2.executeUpdate(...);
          
          //Commit the transaction (apply the changes to the
          //participating databases).
          usertx.commit();
          
          //Release all connections and statements.
          stat1.close();
          stat2.close();
          conn1.close();
          conn2.close();
     }
     ...
 }