JBoss 4.0.0 STATUS_NO_TRANSACTION on commit

[tkvarenes]

When doing an update on a list of locals we get a STATUS_NO_TRANSACTION error message. It looks like it appear when the transaction is to be commited, because it shows in the log with the ID of the first local that was changed/updated. We don't get this error if we run the same code on JBoss 3.2.3.
Does anyone know of any bug in JBoss 4.0.0 that can create this error, or could it be some configuration that we haven't done correct in the JBoss 4.0.0 version?
We have tried to use both Required and RequiresNew, but it makes no different as far as I can see.

org.jboss.tm.JBossRollbackException: Unable to commit, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=ls03/147, BranchQual=, localId=147] status=STATUS_NO_TRANSACTION; - nested throwable: (javax.ejb.EJBException: Update failed. Expected one affected row: rowsAffected=0, id=1556)
at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:344)
at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:457)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:370)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:149)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:128)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
at org.jboss.ejb.Container.invoke(Container.java:854)
at sun.reflect.GeneratedMethodAccessor164.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:242)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104)
at org.jboss.invocation.MarshallingInvokerInterceptor.invoke(MarshallingInvokerInterceptor.java:55)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)

[fluetm]

I'm having the exact same problem moving from 3.2.3 to 3.2.6. I have a cactus test that updates an entity bean which works fine in 3.2.3, but rolls the transaction back when running on 3.2.6. I've seen several posts with a similar issue recently. No responses from jBoss on any of them, though.

From the stack trace below, it almost appears like the entity EJB cannot find the entity in question to update...at first I thought it might be a problem with dirty data, but it's a preexisting row. And that wouldn't explain why 3.2.3 running the same test code against the same database (which is postgreSQL 7.4.3 by the way...not sure if that matters) succeeds.

The transaction attribute is "Required". The trace is posted below

org.jboss.tm.JBossRollbackException: Unable to commit, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=localhost//637, BranchQual=] status=STATUS_NO_TRANSACTION; - nested throwable: (javax.ejb.EJBException: Update failed. Expected one affected row: rowsAffected=0, id=10000000)
at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:415)
at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:456)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:324)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:148)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:111)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331)
at org.jboss.ejb.Container.invoke(Container.java:709)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:419)
at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:83)
at $Proxy315.update(Unknown Source)
at com.dataline.disa.dcts.facade.dao.DctsUserDAO.update(DctsUserDAO.java:412)
at com.dataline.disa.dcts.facade.web.navigation.UserEJBFacade.update(UserEJBFacade.java:196)
at com.dataline.disa.dcts.web.navigation.struts.SetDefaultSpaceActionCactusTest.tearDown(SetDefaultSpaceActionCactusTest.java:54)
at junit.framework.TestCase.runBare(TestCase.java:130)
at org.apache.cactus.ServletTestCase.runCactusTest(ServletTestCase.java:295)
at org.apache.cactus.ServletTestCase.runBare(ServletTestCase.java:263)
at org.apache.cactus.server.AbstractWebTestCaller.doTest(AbstractWebTestCaller.java:156)
at org.apache.cactus.server.AbstractWebTestController.handleRequest_aroundBody0(AbstractWebTestController.java:130)
at org.apache.cactus.server.AbstractWebTestController.handleRequest_aroundBody1$advice(AbstractWebTestController.java:158)
at org.apache.cactus.server.AbstractWebTestController.handleRequest(AbstractWebTestController.java)
at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody2(ServletTestRedirector.java:138)
at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody3$advice(ServletTestRedirector.java:158)
at org.apache.cactus.server.ServletTestRedirector.doPost(ServletTestRedirector.java)
at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody0(ServletTestRedirector.java:109)
at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody1$advice(ServletTestRedirector.java:158)
at org.apache.cactus.server.ServletTestRedirector.doGet(ServletTestRedirector.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)
Caused by: javax.ejb.EJBException: Update failed. Expected one affected row: rowsAffected=0, id=10000000
at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.execute(JDBCStoreEntityCommand.java:155)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEntity(JDBCStoreManager.java:651)
at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity(CMPPersistenceManager.java:369)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.storeEntity(CachedConnectionInterceptor.java:394)
at org.jboss.ejb.EntityContainer.storeEntity(EntityContainer.java:693)
at org.jboss.ejb.GlobalTxEntityMap$2.synchronize(GlobalTxEntityMap.java:134)
at org.jboss.ejb.GlobalTxEntityMap$GlobalTxSynchronization.synchronize(GlobalTxEntityMap.java:253)
at org.jboss.ejb.GlobalTxEntityMap$GlobalTxSynchronization.beforeCompletion(GlobalTxEntityMap.java:302)
at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1362)
at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
... 57 more

[pjdodds]

I have the same problem with a BMT that works under 3.2.3 and is failing with NO_TRANSACTION on 3.2.6.

No code changes between the versions and yet it would appear that 3.2.6 is not handling the transaction the same? does anyone have any experience with this problem?

Cheers

P

[pjdodds]

OK... forget my problem ,just being stupid. Forgot to set the Pad attribute.

Sorry

P

[aloubyansky]

Let's look at this line

Caused by: javax.ejb.EJBException: Update failed. Expected one affected row: rowsAffected=0, id=10000000

Was the instance with that id modified in the transaction?
If someone has a testcase or instructions to reproduce, please, open a bug report at sourceforge.net.
Thanks.

[dhpjboss]

Did you finally solved the problem? please tell me how.

Thank you.