In order to eliminate the overhead of creating a stateless session bean every time using the home interface, I'm thinking of storing the remote interface in the HTTP session. I know this is essential for stateful session beans, but what about stateless session beans? Is this common practice?
thanks in advance.
That is fine. Each EJBObject is *not* tightly coupled to any bean instance and you should cache the EJBObject. You can also cache your EJBHomes. A thread a while back suggested a great deal of people are caching their homes in the ServletContext (application wide) and their EJBObjects in the Session (user wide).
Hope this helps,
Someone told me that storing the stateless session bean in the httpsession may result to poor performance especially for clustered environment because some implementations make loadbalancing decisions during the create call. So if the application stores the stateless session bean in the httpsession, the application risks having all of the workload to only one of the nodes in the cluster.
What's your insight regarding this matter?
Thanks in advance...
I think what u get is reference of EJBObject.You never get reference of bean directly,so if you are storing it then you will be storing the EJBObject but in background container will remove the instance of stateless bean and when you will again call a method then container will pick another instance of it from pool.So i don't think so there will be problem of load balancing.
Since stateless session beans are not client specific what does anyone out there think of the idea of holding them in the servlet context? or would this cause a bottle neck as multiple client could end up accessing the same bean. if the bean had no need to be thread safe (local variables only no synchronized code) would this still be an issue?
What you say is true of a clustered environment. We are just starting clustering and I am learning something new everyday, which usually contradicts a previous belief. ;-)