WebLogic Server Frequently Asked Questions

FAQs: JTA

• How can I incorporate MQSeries as an XA resource for distributed transactions in WebLogic Server?
• 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?
• 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?

Q. How can I incorporate MQSeries as an XA resource for distributed transactions in WebLogic Server?

A. You can download a zip file with instructions, support classes, utilities, and an example from the code samples for weblogic server page on BEA's dev2dev site. You can also directly download the package from ftp://edownload:BUY_ME@ftpna2.bea.com/pub/downloads/wlsmqseries.zip.

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

A. 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.

However, when more than one resource participates in the distributed transaction, you must also set the TxDataSource property EnableTwoPhaseCommit=true. For more information, see Configuring JDBC DataSources in the Administration Console Online Help. 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.

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

A. 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.

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

A. 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 returns 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. 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.

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

A. 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 Using Third-Partjy Drivers with WebLogic Server in Programming WebLogic JDBC.

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

A. Oracle 8.1.7 thin driver has threading problems, so BEA 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 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.

Q. 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?

A. WebLogic jDriver for Oracle has a limitation that closes all open result sets when the method returns to the caller.

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.

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

A. 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.

Q. 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.

A. 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?

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

A. 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.

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

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

Q. 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?

A. 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 minutes. 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.

Contact BEA |  Feedback |  Privacy  |