Announcement Announcement Module
Collapse
No announcement yet.
Graceful recovery from OptimisticLockException Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Graceful recovery from OptimisticLockException

    I have a Roo-managed project, so all my entities have version field and the CRUD views are scaffolded by Roo.

    Whenever two people edit the same entity the one who pressed "Save" button later gets a page with a nasty OptimisticLockException stacktrace. That page is rendered with a catchall java.lang.Exception error-page Roo has installed in web.xml upon project creation.

    This behavior is not user friendly at all. I would like to handle optimistic locks similar to validation errors: re-render the form with the data user entered (so that he doesn't loose it) and display an error message like "Another user has updated the entity while you were editing it".

    How could I do that? The first idea that comes to mind is to push-in Roo-scaffolded update method and catch the exception like this:
    Code:
    @RequestMapping(method = RequestMethod.PUT)
    public String update(@Valid GoodGroup goodGroup, BindingResult result, Model model, HttpServletRequest request) {
        if (result.hasErrors()) {
            model.addAttribute("goodGroup", goodGroup);
            return "goodgroups/update";
        }
    
        try {
            goodGroup.merge();
        } catch (OptimisticLockingFailureException e) {
            result.reject("optimistic_lock");
            return "goodgroups/update";
        }
        return "redirect:/goodgroups/";
    }
    But such an approach defeats the whole purpose of Roo's scaffolding and I would need to add tons of boilerplate code.

    Another option is to handle this via aspect but I'm not that good at AspectJ and I'm not sure whether it is possible at all.

    Does anybody have other ideas?

  • #2
    I don't believe nobody has faced this problem. Am I the only one?

    Comment


    • #3
      Oh no another complainer...
      Does anybody have other ideas?
      Yes, fix it

      But such an approach defeats the whole purpose of Roo's scaffolding
      You don't expect Roo's scaffolding scratch you back and collect your pay check too?

      and I would need to add tons of boilerplate code
      Nope... You just need one line of code.

      B. Roogards
      jD

      Comment


      • #4
        Originally posted by delgad9 View Post
        Oh no another complainer...
        I'm not complaining, just asking for any sound ideas. But your reply was rather offending for no reason.

        Originally posted by delgad9 View Post
        You don't expect Roo's scaffolding scratch you back and collect your pay check too?
        I expect scaffolding tool to do... scaffolding! Surprise! In case you don't know the definition take a look at Wikipedia! In short it's about doing daunting and repetitive tasks for programmer and not vice versa.

        Originally posted by delgad9 View Post
        Nope... You just need one line of code.
        It's not about a single line of code. It's about writing boilerplate code and making workarounds. For every entity you have to take care of this particular issue, then don't forget this one and many others you might face. "Rinse and repeat" for every little entity change, since Roo won't take care about pushed-in methods.

        I thought this forum was for Roo discussion, using the code it generated and improving it. Am I mistaken? Doesn't this problem affect anybody else?

        I know that the Roo team is pretty busy working on Roo and I really appreciate that. I know they cannot please everybody's requests. I'd gladly create a custom add-on to handle this issue, but it resides in addon-web-mvc-controller's code and there's no way to fix it via a custom add-on (please correct me if I'm mistaken).

        Oh, and that my naive solution didn't work anyway - the entity becomes detached inside the catch clause and thus whenever it has any lazy references (a common scenario indeed) to other entities the view render fails with a LazyInitializationException. So I'm still looking for ideas.

        Comment


        • #5
          Sound ideas. Interesting...

          1) On the one line solution: load your model object with an error message like: "Another user has updated the entity while you were editing it... Refresh page and try again". Move the update method to the entity class. You don't have to push the whole project.

          2) I know what scaffolding is... Have you read the fine print of scaffolding?: Probably not. That is the purpose of fine prints: It makes developers lazy and dependent. If is too much kills theirs creativity. Bottom line turns Developers in commodities. Think about that. Roo scaffoling is perfect to me: It removes the tediousness of setting a java web project. It perfectly meets is purpose.

          B Roogards
          jD

          Comment


          • #6
            Madkinder, depending on your project, you might be okay checking for an updated object in the db before allowing the merge. If the object in the db is fresher (has a higher version?) than the object being merged, add a relevant message and return the original page.

            You can also add that exception to your SimpleMappingExceptionResolver in webmvc-config.xml to direct to a particular page in the now-very-rare cases in which the exception is thrown.

            (I think...let us know....)

            Comment

            Working...
            X