> Thanks for your feedback. So the general believe seems that this JEE restriction should not cause problems as long as transaction demarcation and access to transactional resources occurs in a single thread and in a single filter invocation (as opposed to filter does demarcation and servlet uses resources). This sounds reasonable to me and of course Rene's experience with this apporach also makes me confident. And of course I hope that Struts2 gains enough momentum and user base that no app server vendor can afford to break this approach :-)
I'm about to migrate our on-server test suite that currently runs from a servlet to run from a filter. If I find any problems I'll post a follow-up. Gerhard Rene Gielen <gielen <at> it-neering.net> writes: > > 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 <gerhard <at> g-grosse.de> 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." > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
