EJB Pooling


EJB design: EJB Pooling

  1. EJB Pooling (11 messages)

    Hi everybody,

    For what type of beans is pool created by the container?Does all the servers support creation of pooling.

    Threaded Messages (11)

  2. EJB Pooling[ Go to top ]

    Stateless SessionBeans and EntityBeans are pooled. Stateful SessionBeans are NOT pooled.

    Dave Wolf
    Internet Applications Division
  3. EJB Pooling[ Go to top ]

    hello friends

    i seen your conversations ,and why StateFull Sessions are not pooled
  4. EJB Pooling[ Go to top ]

    agree with Rex, why StateFull Sessions are not pooled ????

    i think they r. in fact pretty much sure on that.

    the application server uses specific number of bean instances (in the pool) to manage/hold the state for the clients. its definitely not possible that the server wud create 1000 session bean instances for 1000 users. it uses activaton/passivation mechanism to do the same.

    ur views ??

  5. EJB Pooling[ Go to top ]

    Please see section 6.6 of the EJB 1.1 specification. Stateful SessionBeans are NOT pooled. Once a client calls remove() the bean instance is discarded and may not be re-used. If the bean times out it is also discarded and may not be re-used. If the bean throws a System exception like EJBException or RemoteException the bean instance is discarded and may not be re-used.

    So NO, Stateful SessionBeans are NOT pooled.

    Yes if you have 1000 people they need 1000 EJBObjects in the server. As you state some containers implement Passivation/Activation to clean idle instances from memory by swapping the instance state to persistant storage. However this is NOT pooling as once the client calls remove() the instance is destroyed and eveytime someone calls ejbCreate() the instance is created. Also keep in mind that Passivation/Activation only kicks in when the container wants to. So you should readily accept that if you have 1000 clients you have 1000 instances.

    This is why Stateful SessionBeans are very often suggested to be avoided as they do not scale as well as a Statless pooled instance.

    Dave Wolf
    Internet Applications Division
  6. EJB Pooling[ Go to top ]

    hello friends

    i am totally confused about pooling ,please explain me detaily, it's very usefull for EJBbeginers like me,and tell me how STATEFULL SESSIONS are workouted without POOLING?

    from rexjonathan at rexsmail dot com
  7. EJB Pooling[ Go to top ]

    Iam totally confused.Why the container should will not create pool for statefull beans.If there are 10000 users is it going to create 10000 instances of my bean.What excatly does it do.

  8. EJB Pooling[ Go to top ]

    Because this is how they work!

    Remember a stateful session bean is coupled to a single client so you need an EJBObject for each client as the stateful bean may be maintaining state in an instance member etc. The spec writers chose not to allow them to be pooled to prevent the possibility a developer would not be sure to clean in-memory state before entering the pool. EJB is very conservative in many respects and this is one.

    Dave Wolf
    Internet Applications Division
  9. EJB Pooling[ Go to top ]

    That's correct. Stateful Session Beans cannot be pooled.
    The state diagrams of the beans gives a better picture of the lifecycle of all the beans.
  10. EJB Pooling[ Go to top ]


    this is baffling.

    i just went thru Ed Romans's book (Mastering EJB) and he clearly states(on page 116, second last paragraph) -

    "Ejb does indeed support the effect of pooling stateful session beans. only a few instances can be in memory when there are actually many clients. But this pooling effect does not come for free-the pass./actv. steps could entail an I/O bottleneck..............."

    please respond

  11. EJB Pooling[ Go to top ]

    With all due respect to Ed, that is a poorly worded statement. He is confusing the idea of a pool of idle instances like we would see with a stateless session bean or an entity bean, with the idea of instance swapping which we get with Activation/Passivation.

    I consider a pool to mean when the object leaves the method-ready state, the instance itself is held in an in-memory pool and made available to the next client needing an instance in the method-ready state.

    I consider instance swapping to be the job of the container to take idle instances and passivate their in-memory state to a persistant store to free available memory.

    Also, aside from the I/O performance issue, not every container implements Activation/Passivation so you should never depend on it.

    Does that help?

    Dave Wolf
    Internet Applications Division

  12. EJB Pooling[ Go to top ]


    dave, this actually getting interesting. appreciate ur replies.

    i think what Ed is trying to say here is that the container will create a specific number of (stateful session bean implementation) instances (i.e the pool) and then keep using these specific instances to serve various clients(EJBObject). also to mention that container can re-size the pool at any point of time depending on request/resources.

    there would still be EJBObjects which would equal the number of actual clients(HttpSession) but yes(depending on the container implementation) Stateful Session Bean implementation instances would form some kind of pool. and the container might use bean_instance_2 to serve ejobject_3 not because ejboject_2 has called remove(), but may be because ejbobject_2 is sleeping for the past 2-3 minutes(or whatever time).

    u also talked about pool of idle instances in case of state less session beans. well to the client(EJBObject) it doesnt make a difference whether the instance in the pool is idle or not. the client just needs a bean implementation instance, when it requests for one, which the conatiner(again depending upon the implementation) can either provide from the pool or if need be create another instance(may be, add to the pool too) and return it. and this is true both in case of state-less or stateful beans.

    please do correct if i am wrong.