File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
joseph lam
Greenhorn
Posts: 18
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
ranger
Sheriff
Posts: 17276
6
IntelliJ IDE Mac Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 18
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 18
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic