Home > Error Executing > Error Executing Xaresource.end

Error Executing Xaresource.end


Show Brett Bergquist added a comment - 22/Dec/11 20:10 I found one problem. Hi I am using WebSphere Process Server 6.2, under load testing I am having the following exceptions. There are other cases of calls to getApplicationState which I didn't look at yet. If a later version is available, update to that driver. click site

I am still not clear on the reason that the application connection was being set to null. I don't think it would hurt to do what you suggest but just to let you know, this code is not in production being exercised extensively (private build with this in Server returned XA_R BTIMEOUT. I think I am going to just double check that subsequent operations on the connection start a new local transaction and that the old global transaction is really dead.

Error Executing Xaresource.end

Killing the appsever using "kill" and then attempting to shutdown Derby network server causes the Network Server to hang. got right value Exception in thread "main" java.sql.SQLNonTransientConnectionException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific conditio n for AS INTEGER )) AND (((t2.PLPM_PAIR_ID = t3.ID) AND ((t2.ID = t1.ID) AND (t1.DTYPE = 'PlpmChassis9145E10GUser'))) AND (t0.ID = t1.DEVICE_ENTITY_ID))) with 1 parameters begin parameter #1: 249360 :end parameter ERROR 40XL2: A Caused by: javax.jcr.ItemNotFoundException: A node does not exist with UUID: 47e47f00439e51e384c0aca39882a8ef at com.ibm.icm.jcr.WorkspaceImpl.getNodeByUuid(WorkspaceImpl .java:1160) Problem conclusion Problem Analysis: There were two issues.

  • in this stack trace the frame EmbedStatement#getConnection which has this code: java.sql.Connection appConn = getEmbedConnection().getApplicationConnection(); if ((appConn != applicationConnection) || (appConn == null)) { throw Util.noCurrentConnection(); ---------------------------------------------------------------- repro output Expected Exception
  • Hide Permalink Brett Bergquist added a comment - 27/Dec/11 16:11 It is the IndexStatisticsDaemonImpl that is invalidating the statement.
  • OptionsSort By NameSort By DateAscendingDescendingAttachments appserverstack.txt 22/Dec/11 16:03 63 kB Brett Bergquist client.tar.Z 22/Dec/11 16:02 69 kB Brett Bergquist derby.log 22/Dec/11 15:58 320 kB Brett Bergquist derby-5552_withexpanded_test_diff.txt 23/Feb/12 21:01 9 kB
  • Server returned XA_RBDEADLOCK. : [ibm][db2][jcc][t4][2041][11392] Error executing XAResource.rollback().
  • Since there were no XA transactions, there was not the SYNCCTL with possible missing SYNCCRD exchanges that I was looking for.
  • got right value Exception in thread "main" java.sql.SQLNonTransientConnectionException: No current connection.

As for the other calls not being synchronized, maybe they should be but I don't know. There are 3 other places where conn.setApplicationConnection(null) is called but all three are in XATransactionState.end(), which again, is synchronized on the XATransactionState instance. I had to go into Control Center and change the database application parameter LOCKTIMEOUT to be something other than -1. So whether or not this is the real issue, I don't know but when I tried to get as simple a condition as possible, I ran into this.

Symptom The following message is an example of what you might see if you are not using the latest JDBC driver for your database product: [4/7/13 14:30:39:179 CST] 000000da XATransaction E indicate a driver manager connection and not an xa datasource connection which would have been created in files xads?. ERRORCODE=-4203, SQLSTATE=nullat com.ibm.db2.jcc.b.bd.c(bd.java:453)at com.ibm.db2.jcc.t4.ac.b(ac.java:2675)at com.ibm.db2.jcc.t4.ac.a(ac.java:370)at com.ibm.db2.jcc.t4.ac.commit(ac.java:162)at com.atomikos.datasource.xa.XAResourceTransaction.commit(XAResourceTransaction.java:785)at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:73)at com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:111)at com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:87)at com.atomikos.icatch.imp.Propagator.submitPropagationMessage(Propagator.java:66)at com.atomikos.icatch.imp.CoordinatorStateHandler.commit(CoordinatorStateHandler.java:614)at com.atomikos.icatch.imp.IndoubtStateHandler.commit(IndoubtStateHandler.java:193)at com.atomikos.icatch.imp.CoordinatorImp.commit(CoordinatorImp.java:863)at com.atomikos.icatch.imp.CoordinatorImp.terminate(CoordinatorImp.java:1162)at com.atomikos.icatch.imp.CompositeTerminatorImp.commit(CompositeTerminatorImp.java:92)at com.atomikos.icatch.jta.TransactionImp.commit(TransactionImp.java:236)at com.atomikos.icatch.jta.TransactionManagerImp.commit(TransactionManagerImp.java:498)at com.atomikos.icatch.jta.UserTransactionImp.commit(UserTransactionImp.java:129)at com.Controller.MainController.run(MainController.java:57)at com.util.BatchDriver.main(BatchDriver.java:18)I have the db update statement as well as commit statement http://www.ibm.com/support/docview.wss?uid=swg21640661 Although the residual xa transactions are there in the database, I looked at the client traces and don't see any indication that XA transactions are being used in the test in

In BasicNoPutResultImpl.java around line 250 is the code: try { LanguageConnectionContext lcc = getLanguageConnectionContext(); if(lcc.getRunTimeStatisticsMode() && lcc.getXplainOnlyMode()) { // do nothing } else { openCore(); } } catch (StandardException se) { at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:77) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:158) at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Util.java:262) at org.apache.derby.impl.jdbc.EmbedStatement.getConnection(EmbedStatement.java:1039) at org.apache.derby.iapi.jdbc.BrokeredStatement.controlCheck(BrokeredStatement.java:525) at org.apache.derby.iapi.jdbc.BrokeredStatement.getResultSetHoldability(BrokeredStatement.java:469) at org.apache.derby.iapi.jdbc.BrokeredStatement.(BrokeredStatement.java:63) at org.apache.derby.iapi.jdbc.BrokeredStatement40.(BrokeredStatement40.java:37) at org.apache.derby.iapi.jdbc.BrokeredConnection40.newBrokeredStatement(BrokeredConnection40.java:260) at org.apache.derby.jdbc.XAStatementControl.(XAStatementControl.java:64) at org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:192) at org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(BrokeredConnection.java:100) at derby5552repro.Derby5552Repro.checkConn(Derby5552Repro.java:96) at derby5552repro.Derby5552Repro.main(Derby5552Repro.java:76) Caused ERRORCODE=-4203, SQLSTATE=null find similars IBM DB2 Unknown Component 0 Speed up your debug routine! I think it would definitely be good to get a test checked in too so we don't regress.

So I stopped as much access to the database as I could but still trigger the problem. http://knowledgebase.progress.com/articles/Article/P173414 Hope this helps you. Error Executing Xaresource.end Server returned XA_R BTIMEOUT. I had to go into Control Center and change the database application parameter LOCKTIMEOUT to be something other than -1.

Thanks Mike and Brett for the input. get redirected here Error description Multiple contents scheduled to publish at same time fails with database deadlock exception Local fix N/A Problem summary Problem Summary: PM20585 simultaneous scheduled actions result in deadlocks (lock time-outs) Watson Product Search Search None of the above, continue with my search Database errors XAER_NOTA and XA_RBTIMEOUT in WebSphere Portal SystemOut.log XAER_NOTA ; XA_RBTIMEOUT; DSRA0302E; DB2 Technote (troubleshooting) Problem After performing Hide Permalink Kathey Marsden added a comment - 23/Feb/12 23:45 Running derbyall I see one failure a test specifically for this case expecting no connection. $ cat xaSimpleNegative.diff Start: xaSimpleNegative jdk1.7.0

If applicationConnection is no nulled, could that break the logic in checkExecIfClosed? Portal will start successfully, but after some time these errors begin. Show Brett Bergquist added a comment - 23/Dec/11 00:19 I guess I am confused as well Kathey as I had the debugger attached and do see it going through the XA http://invictanetworks.net/error-executing/error-executing-xaresource-rollback.html If you try rollback it fails with XAER_PROTO but a rollback after end fails with XAER_NOTA if you try to rollback after end.

So nulling out the connection is wrong the way it is. If all that checks out I will check in the change as is. Only registered users can post (registration is free).

When a lock timeout or deadlock is detected, the server calls XATransactionState.cleanupOnError.

The unit of work has already been rolled back in the database but other resource managers involved in this unit of work might not. With DB2 after the lock timeout DB2 doesn't let you use the connection saying Exception trying to check conn2 after lock timeout but before explicit rollback com.ibm.db2.jcc.am.SqlException: [jcc] [t4] [10342] [11669] The effect is that the Lock timeout exception is swallowed and the statement is recompiled and executed again. I don't know if there are any ramifications of doing so at this point however.

Brett Show Brett Bergquist added a comment - 15/Feb/12 12:36 It would be great to have picked the mind of the author of the comment and code but it appeared this The code sees that the statement is invalid and swallows the lock exception and sets up to recompile and run the statement again. Show: 10 25 50 100 items per page Previous Next Feed for this topic United States English English IBM® Site map IBM IBM Support Check here to start a new my review here It also shows that we expected to be able to still explicitly rollback the transaction.

ERRORCODE=-4203, SQLSTATE=null at com.ibm.db2.jcc.am.gd.c(gd.java:453) at com.ibm.db2.jcc.t4.cc.b(cc.java:2733) at com.ibm.db2.jcc.t4.dc.b(dc.java:1540) at com.ibm.db2.jcc.t4.dc.a(dc.java:1320) at com.ibm.db2.jcc.t4.dc.a(dc.java:1315) at com.ibm.db2.jcc.t4.dc.rollback(dc.java:1304) at com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl.rollback(WSRdbXaResourceImp l.java:1336) at com.ibm.ejs.j2c.XATransactionWrapper.rollback(XATransactionWrapper.java: 1315) .... It seems to me that if the exception being caught above is to be “REPORT_ALWAYS”, then the code should never check the statement validity and should just rethrow the original exception. The statement appears not to be valid at that point and a new StandardExceptis thrown with SQLState.LANG_STATEMENT_NEEDS_RECOMPILE and report = REPORT_NEVER. The only thing that I can think of is that the Activation.checkStatementValidity() is seeing the statement as valid and not going to try to recompile it.

Exception ‏2010-07-23T20:45:26Z This is the accepted answer. Show Brett Bergquist added a comment - 03/Jan/12 18:53 I checked the original code and this has been in there since the initial import as far as I can tell from After you run tests, post a patch and mark patch available and I am sure the community will review and expedite commit of the change if it is the right thing. Should this be necessary?

So whether or not this is the real issue, I don't know but when I tried to get as simple a condition as possible, I ran into this. The database is being accessed through EJB's and through Eclipselink and also through a custom JCA interface driving Message Driven Beans. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:122) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) ... 14 more Java Result: 1 BUILD SUCCESSFUL (total time: 21 minutes 51 seconds) Hide Permalink Kathey Marsden added a comment - 01/Feb/12 23:37 Here In this case, it is being invoked right after lock timeout occurs and before the lock timeout exception is being processed.

This finds that the statement is not valid (isValid == false) and throws its own exception indicating that a recompilation is required, swallowing the original lock timeout exception in the process. With my printouts I was seeing that the isValid was being set by the thread that was stuck right after the timeout occurred and then I immediately saw makeInvalid being called The application server is setup with the ClientXADataSource and I do see it calling xa.commit and xa.end for example. This is the one I am not sure about.

This issue is in progress and should be committed soon. Error code is: XAER_NOTA (-4). Error code is: XAER_NOTA (-4). I think most things are working as expected.

Hide Permalink Brett Bergquist added a comment - 03/Jan/12 14:37 This patch removed the null'ing out of the application connection during cleanup from a lock timeout or lock deadlock. a) DB related errors: [8/17/10 14:02:11:108 EDT] 0000005a XATransaction E J2CA0027E: An exception occurred while invoking rollback on an XA Resource Adapter from dataSource jdbc/wpdbDSDB2, within transaction ID {XidImpl: formatId(57415344), gtrid_length(36), The ClientXADataSource is required otherwise the error: Local transaction already has 1 non-XA Resource: cannot add more resources. Immediately the lock timeout got reported and the loop terminated and my test case continued on the way it should.