|bea.com | products | dev2dev | support | askBEA|
|e-docs > WebLogic Server > WebLogic Server Frequently Asked Questions > FAQs: JTA|
WebLogic Server Frequently Asked Questions
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:
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.
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 ../adminguide/managetx.html.
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.
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.