• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Pool for Stateless Session Beans ??

 
Ganesh.P Ram
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ppl,

Am really confused as to whether there is a pool for SLSB like SFSB pool.

HFEJB says that - when ever the client calls the create(), then a new bean and EJBObject is created, bean is associated with EJBObject and EJBObject stub is returned to the client.

As per EdRoman - there is a pool for SLSB also. If there are not enough beans available, then Least Recently Used (LRU) bean from the pool is passivated, and the client is given an already existing bean from the pool.

I was under the impression that for every client a new bean is created.
But Ed Roman seems to suggest that existing beans from the pools can be used. I can appreciate the fact that there would be constraints on the number of beans that is created. But not sure if pool exists.

Please clarify.
 
cheenu Dev
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
head first says " you can think that the container maintains pool of stateless beans. but how does the container implements its really vendor dependent"

so you can think that theres a pool for stateless session beans.

Am really confused as to whether there is a pool for SLSB like SFSB pool.


am too confused what you mean?
stateful session beans dont have pools..is what ejb says.
 
Saeed Amer
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As far I understand, this is vendor specific.

Conceptually, there's one pool for each bean type (i think). So if we deploy a CreditCardBean and a WeatherBean (both stateless), they will each get their own pool.

Statefull beans hold client's conversational state and as such it does not make sense to pool them. If container decides (for whatever reason), these can be passivated and used to serve other clients. The passivated stateful bean can then be activated by container (whenever it decides to) to serve the actual client.

 
Ganesh.P Ram
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ppl,

Sorry, I really messed up with my abbreviations in my last post.
What I meant was - is there a pool for the SFSB (ya..Stateful Session Bean !!!).

This is the correct question -

Am really confused as to whether there is a pool for SFSB like SLSB pool.

HFEJB says that - when ever the client calls the create(), then a new SFSB bean and EJBObject is created, bean is associated with EJBObject and EJBObject stub is returned to the client.

As per EdRoman - there is a pool for SFSB also. If there are not enough beans available, then Least Recently Used (LRU) bean from the pool is passivated, and the client is given an already existing SFSB bean from the pool.

I was under the impression that for every client a new SFSB is created.
But Ed Roman (and my Tech Lead !!!) seems to suggest that existing beans from the pools can be used. Their point is - you cannot keep creating new beans for every user. There wud be a max limit on the number of SFSB that is created. E.g. if there are 2 beans and 4 users, then first 2 users get the beans. Then when the 3rd user requests for the bean, then LRU Bean is passivated, and the existing bean is sent to the client.

btw..one more question here...

During passivation, is the bean passivated (or) are the contents of the bean passivated ? As per my understanding, HFEJB says the bean is passivated and EdRoman suggests that the contents of the bean are passivated. Thats why the same SFSB bean can be allocated to multiple clients.


Sorry for the extremly long question.
 
cheenu Dev
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thus, EJB does indeed support the effect of pooling stateful session beans.

EJB containers exploit this very paradigm

these were the words from mastering ejb book.
also these were there..
But this pooling effect does not come for freeļæ½the passivation/activation steps could entail an input/output bottleneck.

so ejb spec does not mandate this requirement.so it depends on the vendor.
also for stateful session beans in transaction this discussion is not applicable at all.
so you can think of there is no pool for stateful beans(it would be easy that way to distinguish many points with stateless).
you cannot keep creating new beans for every user.

creating stateful beans are much cheaper than passivating and activating them. also if all the clients to stateful beans are active then passivating them to create a new bean is a worst idea.
are the contents of the bean passivated ?

contents are passivated.
Sorry for the extremly long question.

Sorry for the extremly long answer.
[ September 01, 2006: Message edited by: cheenu Dev ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic