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
