Восстановление после исключения оптимистической блокировки Hibernate

Question

В последнее время я столкнулся со странной проблемой. Я попытался изящно обработать исключение устаревшего состояния. Но в блоке catch он по-прежнему вызывает исключение. Ниже приведен фрагмент кода.

public void saveObject(Object ob){
   try{
      sessionFactory.getCurrentSession().saveOrUpdate(ob);
   }catch(org.springframework.orm.hibernate5.HibernateOptimisticLockingFailureException e){
       object latestObject = // get latest object from db;
       copyFieldsFromObToLatestObject(ob,latestObject);
       // print the version of of both object

    LOGGER.info(" ui_version="+ob.getVersion().longValue()+" 
                 entity_version="+latestObject.getVersion().longValue());
          // the ui _version is less than entity_ version as expected 

        sessionFactory.getCurrentSession().saveOrUpdate(latestObject); // at this line I still get the same optimistic locking exception 

   }
}
 /**

 ob2 is the latest object which contains the correct  version hence copying the fields from previous object to this latest object
**/
private void copyFieldsFromObToLatestObject(ob1,ob2){
    ob2.setA(ob1.getA())..
   so on
}

Кто-нибудь может взглянуть на это. Я не могу понять причину, по которой он по-прежнему выдает исключение оптимистичной блокировки после правильной обработки

РЕДАКТИРОВАТЬ 1: трассировка стека:

org.springframework.orm.hibernate5.HibernateOptimisticLockingFailureException: пакетное обновление вернуло неожиданное количество строк из обновления [0]; фактическое количество строк: 0; ожидается: 1; вложенное исключение - org.hibernate.StaleStateException: пакетное обновление вернуло неожиданное количество строк из обновления [0]; фактическое количество строк: 0; ожидается: 1 [ИНФОРМАЦИЯ] в org.springframework.orm.hibernate5.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:283) [ИНФОРМАЦИЯ] в org.springframework.orm.hibernate5.HibernateTransactionManager.convertHibernateAccess.ConvertHibernateAccess. в org.springframework.orm.hibernate5.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:590) [ИНФОРМАЦИЯ] в org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPanagerlatformTransaction.java:765) [ИНФОРМАЦИЯ] на org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:734) [INFO] на org.springframework.transaction.interceptor.TransactionAspectSupportSupport.comTransactionAspectSupport.commit. ] на org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:292) [INFO] на org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionOnterceptor.invoke) или.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) [ИНФОРМАЦИЯ] в org.springframework.aop.framework.JdkDynamicAopProxy.invoke (JdkDynamicAopProxy.invoke (JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213). [].saveOrUpdate(Неизвестный источник) [ИНФОРМАЦИЯ] на biz.kaar.common.services.appointment.impl.AppointmentServiceExtension1BOImpl.handleStaleStateException(AppointmentServiceExtension1BOImpl.java:1520) [ИНФОРМАЦИЯ] на biz.kaar.common.serviceploint.appointment (AppointmentServiceExtension1BOImpl.java:845) [ИНФОРМАЦИЯ] на biz.kaar.common.services.DBServiceImpl.saveSAR(DBServiceImpl.java:382) [ИНФОРМАЦИЯ] на sun.reflect.NativeMethodAccessorImpl.invoke0(собственный метод). [INFO] Reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [INFO] в sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [INFO] в java.lang.reflect.invoke [ИНФОРМАЦИЯ] в net.sf.gilead.gwt.PersistentRemoteService.processCall(PersistentRemoteService.java:115) [ИНФОРМАЦИЯ] на biz.kaar.common.security.AuthorizedGWTServlet.processCall(AuthorizedGWTServlet.java:252) [ИНФОРМАЦИЯ] на biz.kaar.common.services.RemoteServletWithLogging.processCall(RemoteServletWithLogging.java]: com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:373) [ИНФОРМАЦИЯ] на com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceService:62) ] в javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [INFO] в javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [INFO] в org.ecliplet.jetty.serv.ServletHolder.handle(ServletHolder.java:812) [INFO] в org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669) [INFO] в org.springframework.security.habin.CoredoFilter(FilterChainProxy.java:316) [INFO] в org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityIntercep

Answer 1

Проблема была решена, я также копировал версию связанных дочерних объектов в поле to, что приводило к сохранению более старой версии дочерних объектов и, следовательно, к ошибке

Answer 2

В блоке catch вы должны перехватить выброшенное исключение, которое вы хотите обработать. Ты поймаешьOptimistic locking exception. Я даже не могу представить, как это компилируется. Попробовать заменить его на имя исключения в трассировке стека?