[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2877) Seam Managed Transactions doesn't always clean up transactions it starts
[ 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