[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2877) Seam Managed Transactions doesn't always clean up transactions it starts

[Clint Popetz (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.   



> Seam Managed Transactions doesn't always clean up transactions it starts
> ------------------------------------------------------------------------
>
>                 Key: JBSEAM-2877
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-2877
>             Project: Seam
>          Issue Type: Bug
>    Affects Versions: 2.0.2.CR1
>            Reporter: Clint Popetz
>         Attachments: seamPhaseListener-cleanup-tx.diff, tx_except.tar.gz
>
>
> The behavior I'm describing is in servlet code; I have no idea how portlets work.  So the attached patch is not complete.
> The SeamPhaseListener is starting a tx before the restoreView phase.  However, if a runtime exception is thrown in, for example, the conversion and propagation of page request parameters to the event context,  this transaction is marked rollbackOnly by the RollbackInterceptor, but afterServletPhase() will never call handleTransactionsAfterPhase(), and the transaction will never be rolled back.  This leaves an active-but-aborted tx live for that thread. and any subsequent code that tries to use an EJB session bean will trigger further spurious exceptions, because the EJB3 tx is dead.  
> My solution locally was to wrap the final half of afterServletPhase in a finally().   That's kind of a hack, but it does work correctly for me.  It probably needs further investigation.
> I realize that post-exception code is tricky at best, but it seems reasonable to require SeamPhaseListener to at least roll back the tx if it started it, so that whatever work the Exceptions component does has a reasonable JTA state to work with.

-- 
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