Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: 32.97.182.145 is neither permitted nor
 denied by domain of Stan.Bradbury@gmail.com)
Message-ID: <4352D1C9.6090705@gmail.com>
Date: Sun, 16 Oct 2005 15:18:49 -0700
From: Stanley Bradbury <Stan.Bradbury@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: Johan Hoogenboezem <hoogenbj@worldonline.co.za>
CC: derby-user@db.apache.org
Subject: Re: Derby XA, Hibernate 2.1.6,
 WebSphere 5.1 - Server returned XAER_NOTA
 at commit time
References: <002201c5c9aa$62075c40$d80515ac@rmbprivatebank.com>
In-Reply-To: <002201c5c9aa$62075c40$d80515ac@rmbprivatebank.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Johan Hoogenboezem wrote:

>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),
>>data(0000000000000002000000044c4c40cbd49eaa1530e4b7146f080d8853876c7a736572
>>    
>>
>7
>  
>
>>66572314c4c40cbd49eaa1530e4b7146f080d8853876c7a000000048333bb35)}:
>>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.
>Regards
>Johan
>
>-----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:   
>   com.ibm.ws.rsadapter.spi.WSRdbManagedConnection).
>
> 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 
>description.
>
>http://www-1.ibm.com/support/docview.wss?rs=493&context=SWK90&uid=swg1IY7188
>6
>
>  
>
Hi Johan -

I'm not sure where to start so will say I can understand your 
frustration and agree that bringing together an elite team from Derby, 
Hibernate and WebSphere development would be the quickest way to achieve 
a resolution to this issue.  In my experience this is not a simple thing 
to achieve and next to impossible without a Support contract for at 
least one of the products.  In this case the main product involved is 
the transaction manager (TM) within WAS so this is probably the key 
expertise needed - can you initiate a Support case with WAS support?  
The TM is the main component and does appear to be reporting a problem 
(Cannot call 'cleanup' on a ManagedConnection while it is still in a 
transaction) - the question being 'who is calling cleanup and why?'.   I 
believe that obtaining traces from the TM is required to resolve this 
issue - if nothing else WAS support can help in the selection of the 
proper trace flags and in understanding the potentially copius output. 

Regarding the trace information I recommend setting transaction tracing, 
if possible, and searching for occurances of the classes involved in the 
exceptions.  In this case I would be looking for :

  com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanupTransactions
  com.ibm.ejs.j2c.MCWrapper.cleanup
  com.ibm.ejs.j2c.MCWrapper
  com.ibm.ejs.j2c.poolmanager.FreePool.returnToFreePool

 This is because the "Cannot call 'cleanup' on a ManagedConnection while 
it is still in a transaction" message is listed prior to the "XAER_NOTA" 
and so I think preceeds it .  My assumption is that the logging system 
reports error in the order they occur and the order they are listed is 
more significant than the timevalue when the timevalues are close.  Are 
your reading this as the 'XAER' came before the 'cleanup'?  I agree that 
what comes first is usually the more significant.

Lastly, I talked to a developer that worked on the Derby ClientDriver XA 
implementation and she made the following observations.

    The driver has been tested with WAS 6 and is working fine in those 
tests.  WAS 5.1 was never tested with the Derby Client Driver - all 
testing was with Cloudscape 5.1 - she was wondering if you could move 
your system to WAS 6 to see if the problem happens with the current 
WebSphere codeline.   She also mentioned some XA fixes that went into 
the Derby codeline recently and you might try a recent nightly build to 
see it helps with this problem.

Hope this helps.