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

Wed Apr 30 09:32:18 EDT 2008

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

> 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