Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

why stateless bean is not singleton

 
R Jelda
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
It might be a dumb question.
I don't see any importance of pooling stateless beans.

Why not a stateless bean is singleton (one per server in cluster environment).

I have got this doubt till now somany times but no one can clear this.
I would be thankful,if any one of you can help me in explaining main differences.

Whenever I implement a stateless bean, the work is almost like a singleton. Actually I gain performance with singleton (ofcourse). Then why should I use stateless beans in my environment.

One scenario is, I have configurator-component which needs to read configuration from file. Ofcourse this is singleton. why this component needs to be a stateless?

Thanks in advance,
Jelda
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34410
346
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jelda,
The stateless sesion bean can take care of transactions for the client. So while the SSB is executing, only one user can be in it at a time. For a singleton, this would mean you could have only one user in the system. That would bring concurrency to a grinding halt.
 
R Jelda
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Then you mean, if in my application there is no need to maintain Transactions on particular slsbs then I can use singleton instances or?

If so fine. But here I would like to know how others are also using slsb concept even if they don't require Transactions.

please clarify me with some more information.
Thanks in advance,
Jelda
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34410
346
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Transactions are just an example. Another common example is security. If you are not using any of the services an EJB provides, than a singleton is fine.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is more a matter of threading, I think. Unlike a servlet, which is typically instantiated once and then accessed by multiple threads, a session bean instance is accessed by a single thread. The EJB container creates as many bean instances as needed for concurrent requests (each running in a thread), usually subject to a user-defined maximum number.

So, it usually makes no sense to limit the number of instances to one, as this would cause the container to serialize requests to that instance and cause poor performance.
 
sachin pathak
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I am not sure whether this is right thread to ask for some help. Since this topic( threading and related issues for an EJB environment) is very important, can somebody point me to a resource which discusses this thouroughly?

thanks in advance

Sachin
 
Consider Paul's rocket mass heater.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic