Why pool stateless session beans when you can get by with one instance?

[joseph lam]

Since stateless session beans doesn't have states, it seems that we could get by with just one instance per bean type to serve its calls, similar to the servlet model where multiple requests are handled by a single multithreaded servlet - ignoring the possibility of SingleThreadedModel for now.

I understand that each stateless bean call needs to be remote so each "client" can connect to a different remote objects (EJBObject - keeping track of the socket connections (via the rmi stubs/skels)..etc) on the server side. But then each of these ejbobjects can simply delegate to a single bean instance, afterall, it's stateless. So what's the benefits of having a pool of stateless bean instances as described in the EJB spec?

p.s. I actually had this question in my mind 5 years ago but never seemed to find anyone or materials that could answer this satisfactorily.

[Mark Spritzler]

Simply put to handle more throughput of clients. Just like why you have a Connection Pool. So that users don't have to wait. In Tuning applications, one of the biggest strategies for performance tuning is tuning wait points. When a client waits that slows things down, so make pools of stuff so that clients don't have to wait.

Mark

[joseph lam]

However, if the bean is stateless, we can simply multithread through one instance, again, similar to servlet. e.g., 100 stateless bean calls translates to 100 threads through one bean instance (you might still need 100 remote objects - the EJBObject) instead of 100 identical bean instances that doesn't seem to have benefits.

Db connection pool is different - each connection is stateful, typically for the duration of a transaction.

[joseph lam]

I posted this question here also:
https://coderanch.com/t/155413/java-Architect-SCEA/certification/Why-pool-stateless-session-beans