[ http://jira.jboss.com/jira/browse/JBSEAM-2877?page=all ] Clint Popetz updated JBSEAM-2877: --------------------------------- Attachment: seamPhaseListener-cleanup-tx.diff Patch is not complete...but handles the servlet case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2877?page=comments#action_12408458 ] Shane Bryzak commented on JBSEAM-2877: -------------------------------------- Could you please post a use case that reproduces this issue? I'm a little hesitant to wrap the second half of afterServletPhase() in a finally block without being certain there won't be any side effects from doing this. Alternatively, couldn't we simply call handleTransactionsAfterPhase() in the catch block? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2877?page=comments#action_12410589 ] Pete Muir commented on JBSEAM-2877: ----------------------------------- Clint, any chance you could post a test case for this? It sounds like you are correct, but this would make it super easy to verify ;-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2877?page=all ] Clint Popetz updated JBSEAM-2877: --------------------------------- Attachment: tx_except.tar.gz Test case project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2877?page=all ] Pete Muir updated JBSEAM-2877: ------------------------------ Fix Version/s: 2.1.x (was: 2.1.0.BETA1) (was: 2.0.2.CR2) Assignee: (was: Pete Muir) I think it is fair to say that the transaction is in an undefined state inside the exception handler when a system exception occurs. An alternative approach would indeed be to rollback any transaction which is marked for rollback before handling the exception itself, but this is a major resdesign of exception handling. As a workaround, I suggest you check if the transaction is makred rollback in your exceptions component, and if it is, do the rollback and start a new transaction. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2877?page=comments#action_12411325 ] Clint Popetz commented on JBSEAM-2877: -------------------------------------- Sure, I agree, but what about exceptions that don't propogate to, from, or through persistence code? In this case we're talking about an exception from jsf converters. So in that case, we know the persistence context is ok, and it's only the thread-bound tx that is unhappy. I wouldn't think the mere existence of a RuntimeException being thrown/caught would signify a dead persistence context. In any case, starting a tx, then marking that tx as rollback-only, and then not rolling it back seems orthogonal to the question of whether the persistence context is dead. It just seems like buggy behavior. And if everyone that is going to override the Exceptions component is going to need to do rollback a transaction that they didn't start if it's marked as rollbackOnly, at the very least the Exceptions component should provide a method to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2877?page=comments#action_12411342 ] Clint Popetz commented on JBSEAM-2877: -------------------------------------- That is what I'm trying to do. But in our case "logging" means more than just log.error(). We have pretty exact business requirements on who has to be notified, and how they have to be notified, when the site fails. I completely understand that the persistence context has to be considered dead when a runtime exception occurs. I think my complaint about Seam not rolling back its marked-as-rolledBackOnly-tx is still valid, because I see that as a reasonable expectation of consistent behavior from the framework. But I won't be obnoxious and pester you all about it, and I can certainly have my own Exceptions component do that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBSEAM-2877?page=comments#action_12411356 ] Clint Popetz commented on JBSEAM-2877: -------------------------------------- It's puzzling that one should need to defend the existence of exception handling code that must be context aware, model aware, and user role aware, and therefore must live in the same layer as the components for which it is logging exceptions. The suggestion that all of this could be shoehorned under log4j and that by doing so the problem I was describing would go away is either naive or insulting, I can't tell which. Yes, "RuntimeException" means "unexpected behavior" but that doesn't mean "punt." It means "write code that pinpoints exactly what happened, under what circumstances, and to whom, and log it in ways defined by a set of context-dependent rules" and that means interacting with a set of business components which often need to deal with the database. I don't hold hibernate responsible if it throws an exception during this process...I understand that the persistence context is in an unknown state. That's one reason why, for example, I have a separate database and SMPC for inserting the exception logging data. But I also happen to know, from years of working with hibernate and staring at its source, that there are things it _can_ do even in that state, including simple load()s and list()s. All of this scary and forbidden and incredibly important post-exception code has worked for years for me on a complex site with real requirements that is constantly updated. It has even survived several major hibernate revision updates. Now I have a case where something outside of hibernate (Seam) is responding to an exception by leaving JTA in a weird state, which is confusing hibernate, and I again hit this wall of "don't do things after exceptions when using hibernate." To which I can only shake my head and work around it, which I've already stated that I'm doing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira