[
http://jira.jboss.com/jira/browse/JBSEAM-2877?page=comments#action_12408892 ]
Clint Popetz commented on JBSEAM-2877:
--------------------------------------
My use-case is not typical, but I feel it's reasonable. I've overridden the
Exceptions class with a component that extends it and performs extra work (logging,
emailing, etc.) when an uncaught exception occurs. This class uses EJB components to
accomplish its requirements. This works in most cases, but not in the case when the
uncaught exception occurs in a converter or validator for a page parameter. The scenario
then is:
(1) SeamPhaseListener starts a tx before RESTORE_VIEW.
(2) After RESTORE_VIEW, in:
afterServletPhase ->
afterRestoreView ->
postRestorePage ->
Pages.postRestore ->
convertAndValidateStringValuesInPageContext
a page parameter converter throws a runtime exception.
(3) RollbackInterceptor marks the tx as rollbackOnly
(4) SeamPhaseListener never rolls back the tx.
(5) My exception component gets called by afterPhase() in its catch block
(6) It calls in to an EJB which has the default tx semantics of REQUIRES
(7) The EJB tx interceptor will throw an exception here because it needs a tx and current
tx is aborted
With regard to your question "Alternatively, couldn't we simply call
handleTransactionsAfterPhase() in the catch block?" I presume you mean the catch
block of afterPhase. That would also work, assuming we call it before we call
Exceptions.handle(), but there is a possibility that the caught exception will have been
thrown by handleTransactionsAfterPhase() itself, in which case you'd be calling it
twice, and I don't know what effect that could have. I think things are pretty horked
if handleTransactionsAfterPhase() throws an exception, so it's probably ok.
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
Fix For: 2.1.0.BETA1, 2.0.2.CR2
Attachments: seamPhaseListener-cleanup-tx.diff
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