[jboss-user] [JBoss Seam] - EntityHome silently discards updates after errors

In the framework, I'm trying to enforce optimistic locking and a unique constraint on the "name" attribute. For optimistic locking, there's not a lot I can do except kick them out (they can always open a new window and use their back button to copy their changes and merge them in). For name conflicts, I thought to add a message and let them try something else. Here's the code: | @End @Transactional @Override | public String update() { | getInstance().setUpdatedOn(new Date()); | try { | return super.update(); | } catch (OptimisticLockException e) { | facesMessages.add("#{messages.staleEditRule}"); | return "aborted"; | } catch (EntityExistsException e) { | facesMessages.add("name", "#{messages.errNameExists}"); | return null; | } catch (RuntimeException e) { | facesMessages.add(e.toString()); | return null; | } | } | Only problem is, this appears to work -- you correct the name, hit update, your changes appear to take, you're back in the view screen -- but when you next view the entity you edited, you find your changes never actually took. I think I understand why this is happening -- the session is no longer valid after an exception -- but there's no indication even in log messages that this has happened, and the update was just silently dropped. So I have two questions: 1) Is the lost update detectable somehow? I feel like EntityManager should have screamed at me for trying to update again after the exception, but it gave nary a peep. 2) How do I gracefully recover from errors on update and reset the entityManager so further updates can succeed? Should I make the unique constraint a validator instead? Enforcing unique constraints must be a FAQ for Hibernate, but I haven't found an answer yet. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982209#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...