"teknokrat" wrote : | If there are better ways to do this I am all ears. |
Use a transaction. What you have is a unit of work. startWork(); doStuff(); endWork(); JTA Transactions are natural units of work. You can mark when the work starts and when it finishes. More importantly, you can decide when it should timeout and resources get released. Don't get confused about performance. A JTA transaction is just a thread local marker, its not "heavy" like a real jdbc transaction. It can become "heavy" if you enlist something like a jdbc connection in the JTA transaction. Stateful sessions are also units of work but they have some bad semantics in terms of resource allocation. e.g. Suppose the client starts a session, you allocate a tcp/ip connection (a limited resource) per session, but the client then vanishes, e.g. if it is a user interface they go to lunch or go home without ending the session (properly). After a certain period of inactivity JBoss will passivate the session (write it to disk) after a further period of inactivity it will remove the session altogether. Question: How are you going to recover the tcp/ip connection if the session is passivated and then reactivated? You certainly can't serialize a tcp/ip socket. For the same reason, you can't replicate the session across a cluster if you want the session to failover. Another bad feature of SFSB is that a serious error (an EJB/RuntimeException) will mean that ejbRemove() is NOT invoked. That means there is no way for the EJB instance to tell the server to release the resources it allocated. You will leak connections! The EJB spec says you need to do some extra work to cater for this situation, but this is usually hard to do. What this shows is that in general it is bad idea to have the EJBs control resource allocation. You should let the server do it. If you need to use the same connection across requests, use the JTA transaction notion to define what those requests are and let the server "cache" the connection against the transaction. It's called "Transaction Stickiness" on the WIKI page describing the pooling. Anyway, that's enough free consulting. :-) All I can say is that you have been warned that what you are doing is anti-pattern and I've listed some of the main reasons why, plus given you an idea of how to redefine what you are doing as a "unit of work" with better semantics. And I didn't even mention the horrible BMT SFSB semantics. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055304#4055304 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055304 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
