0

In one of our production environments we get hibernatestaleobject exception on a thread continuously after it appears first. This continues till we restart the server.

Environment: oracle 10g, WAS 6.1, Hibernate 2.1

Stack trace is below.

We are unable to simulate this in any other environment.

net.sf.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) for com.cmp1.project1.hibernate.gen.Prjexe instance with identifier: 37120123
at net.sf.hibernate.persister.AbstractEntityPersister.check(AbstractEntityPersister.java:506)
at net.sf.hibernate.persister.EntityPersister.update(EntityPersister.java:687)
at net.sf.hibernate.persister.EntityPersister.update(EntityPersister.java:642)
at net.sf.hibernate.impl.ScheduledUpdate.execute(ScheduledUpdate.java:52)
at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2418)
at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2372)
at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2240)
at com.cmp1.project1.hibernate.client.HibernateClient.update(HibernateClient.java:214)
at com.cmp1.project1.hibernate.client.HibernateClient.update(HibernateClient.java:165)
at com.cmp1.project1.util.project1Utils.persist(project1Utils.java:3018)
at com.cmp1.project1.util.project1Utils.update(project1Utils.java:1166)
at com.cmp1.project1.service.allocation.AllocationImpl.insert(AllocationImpl.java:917)
at com.cmp1.project1.service.allocation.AllocationImpl.create(AllocationImpl.java:239)
at com.cmp1.project1.ejb.allocation.AllocationBean.create(AllocationBean.java:91)
at com.cmp1.project1.ejb.allocation.EJSLocalStatelessAllocation_9d8d9db9.create(EJSLocalStatelessAllocation_9d8d9db9.java:55)
at com.cmp1.project1.ejb.allocation.AllocationClient.create(AllocationClient.java:116)
at com.cmp1.project1.service.processor.ProcessorImpl.processAllocationInstruction(ProcessorImpl.java:2917)
at com.cmp1.project1.service.processor.ProcessorImpl.processFIXMessage(ProcessorImpl.java:568)
at com.cmp1.project1.service.processor.ProcessorImpl.processSingleMessage(ProcessorImpl.java:459)
at com.cmp1.project1.service.processor.ProcessorImpl.processStagedMessage(ProcessorImpl.java:368)
at com.cmp1.project1.service.processor.ProcessorImpl.processMessage(ProcessorImpl.java:259)
at com.cmp1.project1.ejb.processor.ProcessorBean.processMessage(ProcessorBean.java:85)
at com.cmp1.project1.ejb.processor.EJSLocalStatelessProcessor_ac8a6492.processMessage(EJSLocalStatelessProcessor_ac8a6492.java:23)
at com.cmp1.project1.ejb.processor.ProcessorClient.processMessage(ProcessorClient.java:117)
at com.cmp1.project1.service.inbound.AsynchInboundHandlerImpl.process(AsynchInboundHandlerImpl.java:56)
at com.cmp1.project1.ejb.serviceactivator.ServiceActivatorBean.onMessage(ServiceActivatorBean.java:77)
at com.ibm.ejs.jms.listener.MDBWrapper$PriviledgedOnMessage.run(MDBWrapper.java:302)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
at com.ibm.ejs.jms.listener.MDBWrapper.callOnMessage(MDBWrapper.java:271)
at com.ibm.ejs.jms.listener.MDBWrapper.onMessage(MDBWrapper.java:240)
at com.ibm.mq.jms.MQSession.run(MQSession.java:1695)
at com.ibm.ejs.jms.JMSSessionHandle.run(JMSSessionHandle.java:1040)
at com.ibm.ejs.jms.listener.ServerSession.connectionConsumerOnMessage(ServerSession.java:1030)
at com.ibm.ejs.jms.listener.ServerSession.onMessage(ServerSession.java:710)
at com.ibm.ejs.jms.listener.ServerSession.dispatch(ServerSession.java:677)
at sun.reflect.GeneratedMethodAccessor83.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at com.ibm.ejs.jms.listener.ServerSessionDispatcher.dispatch(ServerSessionDispatcher.java:44)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:96)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:132)
at com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java:535)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1497)

Code snippet:

    if(persistObj == null)
        return;

    Session session = sess; 
    try {
        if(session == null)
            session = HibernateUtil.getSession();

        if(LOG.isDebugEnabled() && 
           !(persistObj instanceof NonLoggable))
            log("update", persistObj);

        session.update(persistObj);

        if(flush)
            session.flush();

    } catch(StaleObjectStateException ex) {
        throw new HibernateStaleObjectException(ex);

    } 
siddhesh jog
  • 160
  • 2
  • 9
  • The issue is that once we get a staleobjectexception, it just does not stop. Every database update operation on that thread keeps giving staleobjectexception till we restart server. – siddhesh jog Apr 04 '13 at 11:35
  • Could it be a problem with duplicate ids? Does the row with id 37120123 exist? – Chetter Hummin Apr 04 '13 at 11:37
  • Do you close the session when this exception happens? – JB Nizet Apr 04 '13 at 11:37
  • @JBNizet: yep we are closing the session. – siddhesh jog Apr 04 '13 at 11:44
  • @ChetterHummin: no duplicate ids, have confirmed that several times. The fun part is even for some other id say 3473737 i get the same error message: for com.cmp1.project1.hibernate.gen.Prjexe instance with identifier: 37120123 – siddhesh jog Apr 04 '13 at 11:45
  • @siddheshjog: I have been experiencing this error as well. For me it is not just Staleobject but also the TransientObject NonUniqueObject as well. If you had resolved this, can you please share it here. Thanks. – Kaleid-o-scope Oct 18 '13 at 20:13

1 Answers1

0

Do you re-fetch your persistObj after doing an update? (Your code doesn't show that)

If not, that happens because you update the persistObj. After the update is done, you have an "old" version of persistObj in your class instance. If you want to update the persistObj again, you need to fetch the "current" version of persistObj again.

Manuel
  • 3,828
  • 6
  • 33
  • 48
  • thanks. Will look into it. But apart from that, why is the exception stuck on the thread for ever and ever with the same error message same id , even if another instance with another id is being processed. – siddhesh jog Apr 04 '13 at 11:54