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]
