WebLogic Server Transaction Manager Issues

When XA connection pools are used for the datasources which will involve transactions with the database and other resources, these are the most common issues faced:

1) Exception: : javax.ejb.EJBException: nested exception is: java.sql.SQLException: ORA-02049: timeout: distributed transaction waiting for lock

2) EJB Exception: : javax.ejb.EJBException: nested exception is: java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: XA error: XAER_NOTA : The XID is not valid start() failed on resource ‘CONNECTION_NAME’: XAER_NOTA : The XID is not valid
oracle.jdbc.xa.OracleXAException
at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:882)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:221)
at weblogic.jdbc.wrapper.VendorXAResource.start(VendorXAResource.java:50)
at weblogic.jdbc.jta.DataSource.start(DataSource.java:696)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1145)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1077)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:255)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:449)
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1510)

The XAER_NOTA error raises due to, using two different JDBCConnection Pools for the same Database (Oracle) or two DataSources for the same pool.

XAER_NOTA errors are also seen during recovery.
These errors are thrown for transactions that have been committed before the server restart but still exist in the transaction log at the time the server was booted.
During recovery processing, for each transaction record in the transaction log, the transaction manager will inform the participating resources of the commit decision.
If the resource commit directive succeeded before the restart, the resource manager will respond to a subsequent commit with XAER_NOTA because it no longer has knowledge of the Xid.

The transaction manager ignores this error assuming that the commit succeeded before the crash.

The reason why there are transaction log records that exist for transactions that have already completed is because the transaction manager only removes entries during checkpoint operations.
A checkpoint occurs every five minutes by default and deletes transaction log files for which all records have been released.
The checkpoint interval can be configured via the JTAMBean.CheckpointIntervalSeconds attribute. You can set the Checkpoint Interval in the administration console on the Domain —> Configuration —> JTA tab.

To get more information about the issue, enable the below debug flags on the server:
weblogic.JTAXA
weblogic.JTA2PC
weblogic.JTAJDBC

The javax.transaction.xa.XAResource interface provides a method, setTransactionTimeout, which in some driver implementations sets the resource’s internal timeout interval.

The WebLogic transaction manager can be instructed to invoke this method with a value equal to the global transaction timeout prior to each resource enlistment.

For JDBC connection pool configurations, set the attribute “XASetTransactionTimeout” to “true” to enable this feature.
Note that this JDBCConnectionPool attribute is only applicable for XA-compliant drivers.

Also note that setting this attribute has no affect on XA drivers that do not implement the XAResource.setTransactionTimeout method.

The Oracle thin driver supports XAResource.setTransactionTimeout. The WebLogic jDriver for Oracle driver does not implement this method.

Below are the tunings that should help to resolve the issue:
– Use one connection pool for one datasource.
– Merge the 2 XA pools for one single database.
– Try to set autoCommit to true or call connection.commit() before returning the connection to the connection pool.

Transaction related tunings:
– KeepXAConnTillTxComplete=”true”
– TestConnectionsOnReserve=”true”
– XASetTransactionTimeout=”true”
– XATransactionTimeout=”300″ (This value must be greater than the JTA timeoutseconds value)
– DISTRIBUTED_LOCK_TIMEOUT on the database should be greater than XATransactionTimeout.
– Database Pool XATransactionTimeout should be greater than Global transaction timeout.

If these tunings do not solve the issue, do revert with the debugs enabled for the server so that the logs give more information about the transaction internals.

Best Regards.

15 comments

  1. Hi Divya,

    Very nice one , This site can be named as weblogic at max, it covers everything.

    Thanks all for your hardwork, i referred this site to couple of people

    Keep it up

  2. Hi Neha,

    By resource i mean which ever resource is involved in the transaction. It can be JMS resource, JDBC resource etc (association for a database or message service connection). Timeout can be set for every resource.

    Do let me know if you have any doubts.

    Best Regards,
    Divya

  3. Hi Neha,

    I have listed some of the timeouts in the post. Rest of them will be according to the scenario. They can be more of on the database level.

    Regards,
    Divya

  4. Hi Divya,

    Thank you for some great blog posts. They have been a help in my daily work. I do have a question regarding this post and I hope that you can help me.

    If I understand correctly you write that the resource manager responds with XAER_NOTA when it has committed the transaction and forgotten the XID.

    Is it not possible that the transaction has been rolled back by the resource and the XID forgotten (because it did not get the commit decision and timed out)? If the XID was remembered you usually get a heuristic error.

    You also write: “The transaction manager ignores this error assuming that the commit succeeded before the crash.”

    Is this a behavior that can be changed with a setting? I have a vague recollection that I have seen a WLS behaving strangely, continuously trying to recover an XID until server restart. But it is a while back and I am not quite sure of that particular circumstance.

    I think that I have read that the transaction manager will persist in trying to resolve a pending transaction (in the commit phase) until it succeeds or the Recovery Service times out (default 24h). Or does this only apply then the XAResource actually remembers the XID (but can/will not comply)?

    There seems to be a risk of transaction loss if the transaction manager just ignores the transaction if the resource actually rolled back and forgot the transaction (returning a XAER_NOTA).

    Thanks again for your guidance regarding the fascinating labyrinth called WebLogic.

    Regards,
    Joy

  5. I encountered the same question.And I restart the weblogic server,then the question would be resloved .But I had not know the real reason.

  6. Hi,
    Can you tell me the answers for the questions.
    What are daily activities in WebLogic Admin?
    and
    What are the common Linux commands you use in Weblogic Admin?

  7. Could you please let me know the solution for below error..

    <
    oracle.jbo.DMLException: JBO-26044: Error while getting estimated row count for view object GetRuleTypeForRuleAttributesSDO, statement SELECT count(1) FROM (SELECT * FROM (select * from table (cast (GetRuleTypeForRuleAttributes(:pManagedfacilityid, :pLineid, :pSiteid, :pStartdate,:pEnddate,:pRuletypeid) as RuleTypeForRuleAttribObj_table))) QRSLT WHERE ( ( ( ( P_MANAGEDFACILITYID = :pManagedfacilityid ) OR ( :pManagedfacilityid IS NULL ) ) OR ( ( P_LINEID = :pLineid ) OR ( :pLineid IS NULL ) ) OR ( ( P_SITEID = :pSiteid ) OR ( :pSiteid IS NULL ) ) OR ( ( P_ENDDATE = :pEnddate ) OR ( :pEnddate IS NULL ) ) OR ( ( P_STARTDATE = :pStartdate ) OR ( :pStartdate IS NULL ) ) OR ( ( P_RULETYPEID = :pRuletypeid ) OR ( :pRuletypeid IS NULL ) ) ) )) .
    at oracle.jbo.server.ViewObjectImpl.getQueryHitCount(ViewObjectImpl.java:4690)
    at oracle.jbo.server.ViewObjectImpl.getQueryHitCount(ViewObjectImpl.java:4583)
    at sun.reflect.GeneratedMethodAccessor762.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke

Leave a Reply