db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: Derby XA, Hibernate 2.1.6, WebSphere 5.1 - Server returned XAER_NOTA at commit time
Date Tue, 11 Oct 2005 21:50:21 GMT
Johan Hoogenboezem wrote:

>Hi Stanley
>Thank you for responding.
>I don't know how to do what you ask, though. By the nature of the message
>driven bean in which context the code runs I do not and should not know
>about any open transactions. The container starts the transaction, Hibernate
>senses it is running inside a container transaction (through the way it is
>configured) and defers all transaction handling to the container. The only
>thing I'm allowed to do is to call setRollbackOnly() in case I handle a
>checked exception and decide a rollback is in order. I cannot begin, end or
>commit a transaction without getting an error thrown at me by the container.
>Unless I decouple my persistence code from the container, which I don't want
>to do, because then I don't have distributed transactions anymore. 
>Everything seems ok if XA is not involved. In other words if I have a
>stateless session bean with container managed transactions that do not
>involved messaging or any other XA participants, then I happily do creates,
>reads, updates and deletes through Derby.
>
>I assume Derby does cleanup as a result of some event and that perhaps it
>should be moved to a different event in case of an XA tranasction? Sorry if
>I re-state the obvious. I'm amazed at how often, once I've fixed an error, I
>notice that the exception's been telling me what was wrong all along.
>  
>

> *SNIP*
>
>I've been looking at some of the Hibernate code, and it defers to the
>container for transaction handling, as it should.
>Please let me know if there is anything else I can do.
>This is important as I want my whole team to convert to Derby for
>development.
>Regards
>Johan
>
>  
>
  *SNIP *
    =   =   =   =
Hi Johan -

I only have an academic understanding of container managed transactions 
so please bear with me as I try to understand the problem better.  You 
stated:
    I assume Derby does cleanup as a result of some event and that 
perhaps it
     should be moved to a different event in case of an XA tranasction?

I am not seeing in the stack traces where a derby class is calling 
cleanup - in a container managed architecture would you not expect to 
see derby classes in the trace for this type of failure?   The section 
of the trace included below shows classes prior to entering the 
Exception classes and make it appear that a connection was being 
returned to the pool and caused the WebSphere MCWrapper class to call 
cleanup thus leading to the exception.  Could this be caused by an 
interaction with Derby? 

.ws.rsadapter.AdapterUtil.createDataStoreAdapterException(AdapterUti
.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanupTransactions(WSR
.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanup(WSRdbManagedCon
 .ejs.j2c.MCWrapper.cleanup(MCWrapper.java:1177)  <<<<< <<<<  
 CLEANUP 
called?
.ejs.j2c.poolmanager.FreePool.returnToFreePool(FreePool.java:292)
.ejs.j2c.poolmanager.PoolManager.release(PoolManager.java:1251)
.ejs.j2c.MCWrapper.releaseToPoolManager(MCWrapper.java:1684)
.ejs.j2c.XATransactionWrapper.afterCompletionCode(XATransactionWrapp
.ejs.j2c.XATransactionWrapper.afterCompletion(XATransactionWrapper.j
.ws.Transaction.JTA.RegisteredSyncs.distributeAfter(RegisteredSyncs.
.ws.Transaction.JTA.TransactionImpl.distributeAfter(TransactionImpl.
.ws.Transaction.JTA.RegisteredResources.distributeCommit(RegisteredR
.ws.Transaction.JTA.TransactionImpl.internalCommit(TransactionImpl.j
.ws.Transaction.JTA.TransactionImpl.commit

Might this be a result on the bug I mentioned in my message - 9/20 @ 
5:08 pm:

See  the URL to review  the problem description.
http://www-1.ibm.com/support/docview.wss?rs=493&context=SWK90&uid=swg1IY71886 






Mime
View raw message