FAQs: JTA

 

• Can I use a non-XA driver in distributed transactions?

• Can I use more than one non-XA connection pool in distributed transactions?

• How do XA and non-XA drivers differ in distributed transactions?

• What XA drivers can I use in addition to the WebLogic jDriver for Oracle/XA?

• Can I use the Oracle thin driver as an XA driver in distributed transactions?

• Why do I get SQLException "Result set already closed" message?

• Do I need a 2PC licence when I use JMS with one JDBC non-XA driver?

• Why am I getting an exception when I use JMS with a non-XA driver?

• Why do I get an exception when I use EJB CMP 1.1?

• Why do I get an exception when I use EJB CMP 1.1 with XA connection pools?

• Can I obtain a JDBC connection before I start a distributed transaction?

• Can I close a JDBC connection after the distributed transaction is committed or rolled back?

• I get the following XAER_RMFAIL XAException when accessing an XAResource: "Internal error: XAResource '<name>' is unavailable". What does that mean? How should I handle it?

Can I use a non-XA driver in distributed transactions?

When the non-XA connection pool is the only resource participating in a transaction distributed across multiple servers, you just need to configure a TxDataSource for the non-XA driver. (This configuration is the same as the JTS driver usage in WLS 5.1.)

However, when more than one resource participates in the distributed transaction, you must also set the TxDataSource property EnableTwoPhaseCommit=true. For more information, see Managing JDBC Connectivity in the Administration Guide. In both cases, always obtain a connection via the DataSource interface, not through the deprecated DriverManager interface. If you obtain a connection via DriverManager, the interface cannot pick up the EnableTwoPhaseCommit setting of the TxDataSource; this may result in unexpected behavior in distributed transactions. Also, when you use the DataSource interface, you do not need to distinguish either the URL or the specific WebLogic multitier driver (JTS, RMI, or pool.) The URL and specific driver are obtained through the config.xml file and JNDI lookup.

Can I use more than one non-XA connection pool in distributed transactions?

No. Even if you set EnableTwoPhaseCommit=true for both TxDataSources of the connection pools, attempting to use two non-XA connection pools in the same distributed transaction will result in:

"java.sql.SQLException: Connection has already been created in this tx context for pool named <first pool's name>. Illegal attempt to create connection from another pool: <second pool's name>"

when you attempt to get the connection from the second non-XA connection pool.

How do XA and non-XA drivers differ in distributed transactions?

The differences between XA and non-XA JDBC drivers are:

• Atomicity Guarantee. An XA driver implements the XAResource interface and can participate fully in the 2PC protocol driven by the WLS Transaction Manager. This guarantees atomicity of updates across multiple participating resources.

  However, a non-XA driver does not implement the XAResource interface and cannot fully participate in the 2PC protocol. When using a non-XA driver in a distributed transaction, WLS implements the XAResource wrapper on behalf of the non-XA driver. If the data source property enableTwoPhaseCommit is set to true, then the WLS XAResource wrapper returms XA_OK when the Transaction Manager invokes the prepare() method. When the Transaction Manager invokes commit() or rollback() during the second phase, the WLS XAResource wrapper delegates the commit() or rollback() call to the non-XA JDBC connection. Any failure during commit() or rollback() results in heuristic exceptions. Application data may be left in an inconsistent state as a result of heuristic failure.

• Redirecting Connections. As in WLS 5.1, a non-XA driver can be configured to perform updates in the same distributed transaction from more than one process, as explained in Can I use a non-XA driver in distributed transactions?. WLS internally redirects the JDBC calls made from different processes to the same physical JDBC connection in one process. However, when you use a XA driver, no such redirection will be done. Each process will use its own local XA database connection, and the database ensures that all the distributed updates made in the same distributed transaction from different processes will be committed atomically.

• Connection Management. Whether you are using the non-XA driver or XA driver in distributed transactions, WLS implements JDBC wrappers that intercept all the JDBC calls and obtains a physical JDBC connection from the connection pool on demand.

  • When you use a non-XA driver in distributed transactions, in order to ensure that updates made from different processes are committed atomically, WLS associates the same physical JDBC connection with the distributed transaction until it is committed or rolled back. As a result, the number of active distributed transactions using the non-XA connection pool is limited by the maximum capacity of the JDBC connection pool.

  • When you use an XA driver, the connection management is more scalable. WLS does not hold on to the same physical XA connection until the transaction is committed or rolled back. In fact, in most cases, the XA connection as only held for the duration of a method invocation. WLS JDBC wrappers intercept all JDBC calls and enlist the XAResource associated with the XA connection on demand. When the method invocation returns to the caller, or when it makes another call to another server, WLS delists the XAResource associated with the XA connection.

  • WLS also returns the XA connection to the connection pool on delistment if there are no open result sets. Also, during commit processing, any XAResource object can be used to commit any number of distributed transactions in parallel. As a result, neither the number of active distributed transactions using the XA connection pool nor the number of concurrent commit/rollbacks is limited by the maximum capacity of the connection pool. Only the number of concurrent database access connections is limited by the maximum capacity of the connection pool.

What XA drivers can I use in addition to the WebLogic jDriver for Oracle/XA?

Theoretically, you can use any third party XA driver that is compliant with the JDBC 2.0 standard extension specification with WLS. However, an individual vendor's XA driver may have bugs that prevent it from working properly.

Refer to JDBC Configuration guidelines for details about how to configure them at ../adminguide/managetx.html.

Can I use the Oracle thin driver as an XA driver in distributed transactions?

Oracle 8.1.6 thin driver has a bug that does not accept any foreign Xid, and so does not work at all with any other vendor's transaction manager, including WLS.

Oracle 8.1.7 thin driver has threading problems and we developed the following workaround. We use a dedicated XA connection for the duration of prepare, commit, and rollback operation. This is different from the default XA connection management model (see FAQ 3 for description) in that any XAResource object is used to commit any number of transactions in parallel. This limits the number of concurrent commits to the max capacity of the XA connection pool. Note that this workaround is an Oracle specific workaround and will not affect the usage of other XA drivers.

Meanwhile, if you still want to try it out in SP1 without the workaround, you can configure the XA connection pool. For more information, see Managing JDBC Connectivity in the Administration Guide.

Why do I get SQLException "Result set already closed" message?

Problem: I am using Weblogic jDriver for Oracle/XA (transaction mode) from the client side. Updating in a distributed transaction works fine. However, when I try to perform a query, I get SQLException Result set already closed. How do I work around this?

Weblogic jDriver for Oracle has a limitation that closes all open result sets when the method returns to the caller. For more information, see Limitations of the Weblogic jDriver for Oracle XA in Using WebLogic jDriver for Oracle/XA in Distributed Transations.

Using the driver from the server side, for example, in a bean, does not have this limitation. Using the driver from the server side is also recommended from application architecture and performance perspective. Using the driver from the client side incurs round-trip cost for every JDBC call being made.

This limitation exists because Weblogic jDriver for Oracle XA is implemented using Oracle's OCI API and C XA switch, and there is an Oracle problem when using OCI with XA in multi-threaded mode. Closing an OCI cursor in a thread that is different than the thread in which it is opened may result in server crash or unexpected behavior. As a result, the Weblogic driver implicitly closes all open result sets upon returning a call to the caller.

Do I need a 2PC licence when I use JMS with one JDBC non-XA driver?

Yes, you do. JMS is also a XAResource that participates in the distributed transaction. Therefore, there are two resources participating in the distributed transaction, and a 2PC license is needed.

Why am I getting an exception when I use JMS with a non-XA driver?

Problem: I am using JMS with one JDBC non-XA driver. Transaction fails to commit with the following exception javax.transaction.xa.XAException: JDBC driver does not support XA, hence cannot be a participant in two-phase commit.

As mentioned in the previous question Do I need a 2PC licence when I use JMS with one JDBC non-XA driver?, JMS is also a XAResource that participates in the distributed transaction. When more than one resource is participating in the distributed transaction, you need to set the data source property EnableTwoPhaseCommit=true as explained in "Can I use a non-XA driver in distributed transactions?"

Why do I get an exception when I use EJB CMP 1.1?

Problem: I am using distributed transactions with EJB CMP 1.1 and a non-XA connection pool. I configured the JDBC connection pool and the TxDataSource according to instructions in Can I use a non-XA driver in distributed transactions?. However, commit still gives javax.transaction.xa.XAException: JDBC driver does not support XA, hence cannot be a participant in two-phase commit. Why?

The old style CMP 1.1 DTD does not allow you to specify the data source name. When only the connection pool name is specified, the EnableTwoPhaseCommit setting of the TxDataSource is ignored. You should use the new style CMP 1.1 DTD and specify the data source name instead of the pool name. See http://www.bea.com/servers/wls600/dtd/weblogic-rdbms11-persistence-600.dtd.

Why do I get an exception when I use EJB CMP 1.1 with XA connection pools?

Problem: I am using distributed transactions with EJB CMP 1.1 and with two XA connection pools. I configured the XA JDBC connection pools and the TxDataSource according to instructions in Managing JDBC Connectivity in the Administration Guide. However, I get the following exception: "Couldn't get connection: java.sql.SQLException: Connection has already been created in this tx context for pool named <pool name> Pool. Illegal attempt to create connection from another pool: <pool name> Pool". Why?

Answer: The old style CMP 1.1 DTD does not allow you to specify the data source name. When only the connection pool name is specified, the code path for non-XA connection pools will be mistakenly executed instead. You should use the new style CMP 1.1 DTD and specify the data source name instead of the pool name.

To ensure that the descriptor is using the latest DTD file, verify that the DOCTYPE header for the WebLogic CMP 1.1 descriptor file is as follows:

<!DOCTYPE weblogic-rdbms-jar PUBLIC 
'-//BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB 1.1 RDBMS 
Persistence//EN'
http://www.bea.com/servers/wls600/dtd/weblogic-rdbms11-persistenc
e-600.dtd'>

To see the DTD file, go to http://www.bea.com/servers/wls600/dtd/weblogic-rdbms11-persistence-600.dtd.

Can I obtain a JDBC connection before I start a distributed transaction?

This depends on whether you are using a non-XA or XA driver.

• When you use a non-XA driver in a distributed transaction, always obtain a JDBC connection after the distributed transaction is begun.

• If you are using an XA driver, you can obtain the connection before or after the distributed transaction begins.

Can I close a JDBC connection after the distributed transaction is committed or rolled back?

For both non-XA and XA driver, you can close the connection after the distributed transaction is completed.

I get the following XAER_RMFAIL XAException when accessing an XAResource: "Internal error: XAResource '<name>' is unavailable". What does that mean? How should I handle it?

JTA has its own resource health monitoring that works as follows:

A resource is considered active either if there are no pending requests or if we get a result from any of the XAResource pending requests that is not an XAER_RMFAIL. If an XAResource is not active within the two minutes, it is declared dead. Any further requests to the XAResource are shunned, and an XAER_RMFAIL XAException as above is thrown. The intent is to prevent further loss of threads if the RM is dead.

A resource is declared active again, if you re-register the XAResource with the WebLogic Server Transaction Manager by calling weblogic.transaction.TransactionManager.unregisterResource followed by registerStaticResource or registerDynamicResource, or after a timeout period of 30 mins. If you are using WLS JDBC connection pools, you only need to enable the JDBC connection pool refresh feature (by specifying the "RefreshMinutes" property of the connection pool), and, upon a successful connection pool refresh, the corresponding XAResource will be re-registered automatically. If you are registering your own XAResource, either via weblogic.transaction.TransactionManager.registerStaticResource or registerDynamicResource APIs, you will need to re-register the XAResource by calling weblogic.transaction.TransactionManager.unregisterResource followed by registerStaticResource or registerDynamicResource.

In general, a good way to debug potential RM problems is to turn on JTA XA debugging, by specifying -Dweblogic.Debug=weblogic.JTAXA as JVM parameter on WLS startup.