db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johan Hoogenboezem" <hooge...@worldonline.co.za>
Subject RE: Derby XA, Hibernate 2.1.6, WebSphere 5.1 - Server returned XAER_NOTA at commit time
Date Wed, 05 Oct 2005 12:43:13 GMT
Hi Stanley
Thank you for your suggestion. I had a look at the link you sent me and made
sure I had the latest fixpack (for WSAD 5.1.2)loaded. It had no effect on
the problem. 
I feel I should point out that the error you latched on to was one of the
last ones listed. In my experience the first error in a cascade of errors is
usually the important one:

>[9/13/05 8:23:49:819 CAT] 1e59f386 WSRdbXaResour E DSRA0304E:  XAException
>occurred. XAException contents and details are: The cause is
>org.apache.derby.client.am.SqlException: Error executing a
>XAResource.commit(), Server returned XAER_NOTA.
>[9/13/05 8:23:49:819 CAT] 1e59f386 WSRdbXaResour E DSRA0302E:  XAException
>occurred.  Error code is: XAER_NOTA.  Exception is: XAER_NOTA : Error
>executing a XAResource.commit(), Server returned XAER_NOTA
>[9/13/05 8:23:49:889 CAT] 1e59f386 XATransaction E J2CA0027E: An exception
>occurred while invoking commit on an XA Resource Adapter from dataSource
>jdbc/derby/scvwebdev, within transaction ID {XID: formatId(57415344),
>gtrid_length(39), bqual_length(28),
>org.apache.derby.client.am.XaException: XAER_NOTA : Error executing a
>XAResource.commit(), Server returned XAER_NOTA
>	at
>org.apache.derby.client.net.NetXAResource.throwXAException(Unknown Source)
>	at org.apache.derby.client.net.NetXAResource.commit(Unknown Source)
>	at
> etc. etc. etc.

The later errors are usually side effects which go away when the real
problem is solved. From analyzing the javadoc of the standard JTA api's it
is clear that if the "destroy" method is called when a transaction is not in
an "idle" state, then further errors will be generated. The container calls
the destroy method, even though the commit resulted in an error, so further
errors are almost assured.

In any case, I tried to enable tracing as you suggested - and quickly got
lost in the quagmire of log files and more log files. I am completely lost
here as I have no documentation that can explain to me what the trace means.
I can provide the trace log if anyone wants it, though.

I then resorted to re-building Derby with some debug statements. I was
flying blind here, too, which is what one does when desperate. I also get
nowhere, having no knowledge of the inner workings of a JTA implementation.

So, it seems I'm stuck.

For me, it seems to be a pretty simple matter of a derby developer
(preferably the guy/girl who worked on the XA stuff :-)) to get together
with an IBM WebSphere (v5.1.x) guy (IBM donates development time to Derby,
right?), and then for this elite team of two to knock up a quick example of
responding to a JMS message and accessing a Derby datasource suitably
embedded in a Hibernate session. I can provide some code examples that will
help reproduce the problem. I've invested a lot of time in getting
Hibernate, Session beans, MDBs and datasources to co-exist peacefully (at
least for DB2). So at least that was worth the effort.

I'd be very grateful if someone can help with this. I would really like to
use Derby exclusively as my development rdbms. I rather like the idea of a
RDBMS written in Java.

-----Original Message-----
From: Stanley Bradbury [mailto:Stan.Bradbury@gmail.com] 
Sent: Wednesday, September 21, 2005 2:09 AM
To: Derby Discussion
Subject: Re: Derby XA, Hibernate 2.1.6, WebSphere 5.1 - Server returned
XAER_NOTA at commit time

Hi Johan -
I had hoped to find more for you on either the hibernate or the 
WebSphere site but only found one reference to this error.  This problem 
report suggests that a 'fix' may be available from IBM (this is a Tivoli 
product  but Tivoli uses WebSpere and this did happen in the same class 
indicated in your trace:   

 It also sounds like the problem was related to threads not being in 
sync (..use more thread-safe functions).  I think the next step in 
resolving this would be to turn on tracing in WebSphere to see if  the 
additional information indicates why there is still an open 
transaction.  Here is the URL to review  the description problem 


View raw message