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]
