-
1. Re: Despite Exception the code in component continues to execute
arsenalist Mar 17, 2009 7:42 PM (in response to arsenalist)Did some more Googling and found a couple more threads asking the same question without any answer:
http://seamframework.org/Community/RemoveEntityWhichHaveAnChild
http://www.mail-archive.com/jboss-user@lists.jboss.org/msg04902.html//www.mail-archive.com/jboss-user@lists.jboss.org/msg04902.html
-
2. Re: Despite Exception the code in component continues to execute
mankal Mar 17, 2009 8:51 PM (in response to arsenalist)Just an idea, but is it possible that the exception is thrown after the method completed and when the transaction is being committed?
-
3. Re: Despite Exception the code in component continues to execute
arsenalist Mar 17, 2009 9:47 PM (in response to arsenalist)Yes, you're right. But still don't know how to catch this exception and prevent calling code form being executed after the exception. The following method resides in another Seam component and is being called from the Facelet. How do I prevent it from displaying both messages?
public void delete() {
log.debug(before
);
userManager.remove(user);
facesMessages.addFromResourceBundle(user.delete.success
);
log.debug(after
);
}After some debugging I found out that the commitOrRollback() method in SeamPhaseListener is doing the commit but that gets called after my component method is executed.
Any ideas?
-
4. Re: Despite Exception the code in component continues to execute
mwohlf Mar 17, 2009 10:03 PM (in response to arsenalist)can you try
((Session)entityManager.getDelegate()).flush();
right after the
userManager.remove(user);
to see if this triggers the exception earlier ?
-
5. Re: Despite Exception the code in component continues to execute
arsenalist Mar 17, 2009 10:18 PM (in response to arsenalist)Thanks for the tip.
In my EJB I do the following:
em.remove(user);
em.flush();and that forces it to commit. I'll settle for this solution for now.
Thank you for your help.
-
6. Re: Despite Exception the code in component continues to execute
arsenalist Mar 18, 2009 6:23 PM (in response to arsenalist)I just want to emphasize that this solution isn't ideal. Isn't there a way to prevent code in a component method from being executed on an exception. Somehow committing the transaction earlier than normal doesn't strike me as the best way of doing this.
-
7. Re: Despite Exception the code in component continues to execute
dan.j.allen Mar 19, 2009 9:48 AM (in response to arsenalist)I get what you want to have happen, but I'm not sure you are understanding the semantics of JPA in this case. In JPA, all data manipulating statements are executed as late as possible. You are not seeing the exception in the action method because it's not being thrown then. As the thread points out, if you are expecting the change to occur within the method, you need to call flush(). That is not a hack. You are asking JPA to alter it's default behavior (because in this case it is not want you want) and instead move forward with the DML statements immediately.
If the delete method is a JSF action and you don't have manual flushing enabled, you should see an error page rather than the normal navigation outcome because Seam will commit the transaction at the end of the Invoke Application phase, thus triggering a flush and in turn your expected failure. That's because a flush happens when a transaction commits (unless manual flushing is activated on a Hibernate-backed EntityManager).
-
8. Re: Despite Exception the code in component continues to execute
luxspes Mar 19, 2009 1:23 PM (in response to arsenalist)
Dan Allen wrote on Mar 19, 2009 09:48:
I get what you want to have happen, but I'm not sure you are understanding the semantics of JPA in this case. In JPA, all data manipulating statements are executed as late as possible.
.
Or at least, they should be executed as late as possible. But it is not consistently true
You are not seeing the exception in the action method because it's not being thrown then. As the thread points out, if you are expecting the change to occur within the method, you need to call flush(). That is not a hack. You are asking JPA to alter it's default behavior (because in this case it is not want you want) and instead move forward with the DML statements immediately.