Never realized this before, very interesting. The key point with Struts2
is that from the perspective of the JEE API, the request handling is
nothing more than one single filter method call, in one single thread.
As Nils-Helge already mentioned, since no Servlet is involved, there
should not be any problem.
I'm using Interceptor based transaction demarcation for years now (since
back in the WebWork days), and it always worked perfect in any scale of
application, in lots of different containers.
An implication I see is that if you were used to work with the
OpenSessionInView-Filter pattern, you should switch to a Interceptor
based solution if you are lucky enough to use Struts2, because the
Filter solution clearly violates the spec then.
- Rene
Nils-Helge Garli Hegvik schrieb:
Interesting question. I don't have an answer, and I'm certainly no JEE
spec expert, but I've been trying to do some research. From what I
understand, this restriction exists because there's no guarantee that
the filter and the service method of the servlet it filters executes
in the same thread. However, if that was a typical approach for
containers to use it would invalidate any OpenSessionInView or similar
filters that do transaction handling/thread locals in the filter
method, which is pretty common everywhere. Also, the FilterDispatcher
doesn't actually pass control on to a servlet. It executes the action
within the filter method. So while it's possibly a spec violation, I'm
not sure it's possible to encounter the situation the restriction is
set to protect.
Bottom line: I'm not sure. Hopefully, someone with more expertise and
detailed knowledge can join the discussion and clear things up.
Nils-H
On Sun, Nov 23, 2008 at 11:56 AM, Gerhard Große <[EMAIL PROTECTED]> wrote:
Hi,
we are currently evaluating to migrate a Struts 1 J2EE-Application to Struts 2
and discovered something which might be a major problem or might not, which is
what I am trying to find out:
In section J2EE.4.2.1 the J2EE specifications (1.3, 1.4 and 5.0 at least)
states:
"Servlet filters and web application event listeners must not demarcate
transactions using the javax.transaction.UserTransaction interface. Servlet
filters may use transactional resources in a local transaction mode within their
doFilter methods but should not use any transactional resources in the methods
of
any objects used to wrap the request or response objects."
Now Struts 2 does call its actions from within the FilterDispatcher servlet
filter and in our application the action methods would call into our business
logic components which do demarcate transactions using the UserTransaction
interface. Therefore we wonder if this might cause problems.
We are using WebSphere (v6.1) as application server. First experiments showed
that the UserTransaction (via the JNDI lookup java:comp/UserTransaction) is
available and can be used within the Struts 2 action. However a started
transaction is not rolled back if the application code fails to commit it (in
case of an Error thrown, for example). In this case further requests executed on
the same the thread generate an exception when an attempt is made to start a new
transaction. This is different from the behavior in Struts 1 actions, which are
called from a servlet: Here the transaction is cleaned up by the container, no
matter what the application code does or does not.
So it seems that using UserTransactions with Struts 2 more or less works with
WebSphere but it might be more like an undocumentated "feature" of WebSphere
that might be dropped in the future.
Is this something that has been taken into consideration when designing Struts 2
to call actions from within a servlet filter? Are there any workarounds / best
practices / advices how to deal with this potential problem?
We have started to love to work with Struts 2 and would hate it if we had to
drop our migration project because of this detail.
Any feedback on this issue would be highly welcome.
Gerhard=
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
Cel: +49-(0)177-3194448
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
