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