3 Replies Latest reply on Sep 12, 2005 9:43 AM by milx

    Flush needed to check @Version on delete

    milx

      This post is related to my previous post on optimistic locking exception handling, http://www.jboss.com/index.html?module=bb&op=viewtopic&t=68810.

      I have an interceptor class that wraps each call to my stateless session bean, trying to catch StaleObjectStateExceptions thrown by Hibernate, and throw my application specific VersionException (simplified):

      @AroundInvoke
      public Object intercept(InvocationContext ctx) throws Exception {
       try{
       return ctx.proceed();
       }
       catch (org.hibernate.StaleObjectStateException e) {
       throw new VersionException();
       }
       finally{}
      }

      I can catch the StaleObjectStateException when I call the merge(Object) method on the EntityManager with a dirty object, but not when I call delete(Object). In the latter case, the StaleObjectStateException is thrown after my interceptor has finished. However, if I explicitly call flush() on the EntityManager in my session bean after the delete call, the StaleObjectStateException is thrown right away and I can catch it in my interceptor.

      So my question is; do I have to explicitly call flush() to be sure that exceptions thrown as a result of database synchronization really are thrown within the current InvokationContext?

      Again, thanks in advance for any replies.
      Regards,
      Trygve