Hi, we are currently evaluating to migrate a Struts1 J2EE-Application to Struts2 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 Struts2 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 Struts2 action. However a started transaction is not rolled back if the application code fails to do a commit or rollback (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 Struts1 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 Struts2 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 Struts2 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 Struts2 and would hate it if we had to stop 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]
