Error Deleting JMSMessage
Stefan Kupferschmid
Hi,
I'm running Weblogic 5.1 SP 8, with EJB SessionBean and weblogic's JMS
and Orcal 8 as persistent storage.
When the container tries to commit while leaving the business method, an
javax.jms.JMSException: Error Deleting JMSMessage
is thrown.
Had someone a similar problem or an idea why this happens.
Find below more of the stack trace.
Kind regards,
Stefan
Sat May 19 20:32:22 CEST 2001:<I> <TX> Transaction rolled back due to beforeCompletion
exception
javax.jms.JMSException: Error Deleting JMSMessage
at weblogic.jms.common.JMSUtilities.jmsException(JMSUtilities.java:18)
at weblogic.jms.server.JDBCStore.deleteMessage(JDBCStore.java:853)
at weblogic.jms.server.QueueSessionState.acknowledge(QueueSessionState.java:91)
at weblogic.jms.server.SessionState.updateAcknowldgements(SessionState.java:537)
at weblogic.jms.server.SessionState.beforeCompletion(SessionState.java:776)
at weblogic.jts.internal.CoordinatorImpl.notifyBefore(CoordinatorImpl.java:616)
at weblogic.jts.internal.CoordinatorImpl.prepare(CoordinatorImpl.java:410)
at weblogic.jts.internal.CoordinatorImpl.commit(CoordinatorImpl.java:361)
at weblogic.jts.internal.TxContext.commit(TxContext.java:255)
at weblogic.ejb.internal.StatefulEJBObject.postInvokeOurTx(StatefulEJBObject.java:300)
at weblogic.ejb.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:758)
at atraxis.products.dupecheck.DupeDetectorBeanEOImpl.doWork(DupeDetectorBeanEOImpl.java:261)
Don
Stefan,
This error is thrown when either JMS can't connect
to the database or the message could not be deleted
for some reason. Try turning on the JDBC log file
& run it again. Then check the log file to see if
the actual SQL is there, or if there are any
DB-specific errors that occur. Is the connection
to the DB OK? Can you run SQL queries?
Don
"Stefan Kupferschmid" <skup...@atraxis.com> wrote in
news:3b0910e3$1...@newsgroups.bea.com:
Joe Ammann
> Stefan,
>
> This error is thrown when either JMS can't connect
> to the database or the message could not be deleted
> for some reason. Try turning on the JDBC log file
> & run it again. Then check the log file to see if
> the actual SQL is there, or if there are any
> DB-specific errors that occur. Is the connection
> to the DB OK? Can you run SQL queries?
Let me reply on this, I'm working together with Stefan on this:
What we have found is that the error that happens is because WLS 5.1
does not allow 2 different JDBC connection pools in the same
transaction.
---- Excerpt from jdbc.log
java.sql.SQLException: Connection has already been created in this tx context for pool nam
ed globalDataPool. Illegal attempt to create connection from another pool:oracleJdriverPoo
l
at weblogic.jdbcbase.jts.Driver.connect(Driver.java:255)
at weblogic.jms.server.JDBCStore.getConnection(JDBCStore.java:1246)
at weblogic.jms.server.JDBCStore.deleteMessage(JDBCStore.java:845)
at weblogic.jms.server.QueueSessionState.acknowledge(QueueSessionState.java:91)
at weblogic.jms.server.SessionState.updateAcknowldgements(SessionState.java:537)
at weblogic.jms.server.SessionState.beforeCompletion(SessionState.java:776)
at weblogic.jts.internal.CoordinatorImpl.notifyBefore(CoordinatorImpl.java:616)
at weblogic.jts.internal.CoordinatorImpl.prepare(CoordinatorImpl.java:410)
at weblogic.jts.internal.CoordinatorImpl.commit(CoordinatorImpl.java:361)
at weblogic.jts.internal.TxContext.commit(TxContext.java:255)
at weblogic.ejb.internal.StatefulEJBObject.postInvokeOurTx(StatefulEJBObject.java:300)
at weblogic.ejb.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:758)
at atraxis.products.dupecheck.DupeDetectorBeanEOImpl.doWork(DupeDetectorBeanEOImpl.java:261)
at atraxis.products.dupecheck.DupeDetectorBeanEOImpl_WLSkel.invoke(DupeDetectorBeanEOImpl_WLSkel.java:53)
at weblogic.rmi.extensions.BasicServerObjectAdapter.invoke(BasicServerObjectAdapter.java:347)
at weblogic.rmi.extensions.BasicRequestHandler.handleRequest(BasicRequestHandler.java:77)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:15)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129)
I _know_ that it is illegal to have 2 different pools inside the same
transaction, but still, this one appears weird to me. Here's why:
We basically have 2 JDC (Oracle jDriver) pools in our application. One
is used for almost all beans, as well as JMS (oracleJdriverPool), the
other one (globalDataPool) is used for a shared "world representation"
(things like cities and countries) which is shared among multiple
containers.
Read-Only CMP EntityBeans access this globalDataPool, but _all_ are
marked with TX_NOT_SUPPORTED.
So what I was expecting is that "distributed transactions" in WLS 5.1
(including JMS accesses) will work fine, because all accesses are done
on the same data pool (the oracleJdriverPool). The globalDataPool is
used exclusively by beans with TX_NOT_SUPPORTED, so it should not
matter to WLS with regard to transaction scope!
So I thought! But what seems to happen is that WLS still is very
pessimistic, and bails out on the transaction. Of course, the actual
transaction does include calls to the "GlobalData beans", but those
should not be included, since they are TX_NOT_SUPPORTED!
Or did I get anything wrong here?
Anyway - this is what this symptoms actually boil down to, and until
now we have found the following solutions:
1) Make JMS Queues non persistent. Strangely enough, this works! In
this case, there are bean accesses to 2 different JDBC pools within
the same transaction. But here, my assumption seems to hold true
(that marking beans as TX_NOT_SUPPORTED also excludes the pool from
the transaction)
2) Using the same JDBC pool for all beans. Easy enough, we can always
keep having one single copy of the "world representation data" in
the DB, and map it to other schemas with SYNONYMS
Still, I'm tempted to call this a WebLogic bug. I'll do some more
investigation and keep you informed.
CU, Joe