View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3820726#3820726
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3820726 "[EMAIL PROTECTED]" wrote : Thinking about it a little further, even the TX interceptor case state is only meaningful for the lifetime of that invocation. Keeping the state around in memory of the server when there is no ongoing invocation seems a little wasteful. Consider for instance a POJO I've instrumented as transactional. This POJO gets invoked once a week. Why should I keep the state of that transactional interceptor in memory on my server for a whole week if I only need it for few milliseconds once a week. For such a case it would make sense (from resource usage point of view) to have a stateless TX interceptor and hold that state in memory for the few milliseconds it takes to invoke my POJO. With EJB we did not have this issue as the interceptor stack was per container, not per object identity. Stateful implementations are usually easier to implement than stateless though. However, people have managed to build easy-to-use APIs on top of stateless HTTP invocations (Servlet API) that hides the complexity from the developer so why could we not do the same? Is implementing servlet Filters difficult, do we need a different model from that? Again, I don't think this is an either/or proposition. Bill ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
