Win a copy of Pro Spring MVC with WebFlux: Web Development in Spring Framework 5 and Spring Boot 2 this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Bear Bibeault
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:
  • Frits Walraven
  • Himai Minh

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

 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
ranger
Posts: 17346
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I posted this question here also:
https://coderanch.com/t/155413/java-Architect-SCEA/certification/Why-pool-stateless-session-beans
 
reply
    Bookmark Topic Watch Topic
  • New Topic