EJB design: Bean Pooling vs. Instance Pooling

  1. Bean Pooling vs. Instance Pooling (2 messages)

    I am reading the following, and don't know what is the difference between bean pooling and instance pooling. "Statful session beans maintain state both within and between transactions. Each stateful session bean is therefore associated with a specific client. Containers are able to save and retrieve a bean's state automatically while managing instance pools (as opposed to bean pools) of stateful session beans." My understanding is: - instance pooling: a bean instance is never shared by different clients, meaning one bean is activated and perhaps another is passivated at the same time using LRU algorithm. - bean pooling: a bean instance will be re-used by different clients Any help will be appreciapted. Thank you,
  2. Re: Bean Pooling vs. Instance Pooling[ Go to top ]

    Michael, My thoughts on this: Before getting to instance vs. bean pools, an EJB is never shared between two clients *at the same time*. This guarantee makes them threadsafe. Stateless beans, by nature, need not know their clients once the remote business method returns. These beans can therefore be bean-pooled. On the other hand stateful session beans may be requested back(with previous state) by a client using the javax.ejb.Handle reference that the client may have retained. In this case, the bean will need to be re-instated entirely. These beans therefore can only be instance-pooled and never shared between clients. Activation and passivation in either case is driven by the same rules based on resource(JVM Heap) availability.
  3. Bean pooling vs Instance Pooleling[ Go to top ]

    Hi, The idea of instance / bean pooling (whatever u call) is pretty simple . For stateless beans because we dont maintain the state all the beans in pooled state are same and can be used by any client needing its service . But for stateless beans all the instances when in pool are similar . But once they are associated with a remote stub the instance is no more similar to the ones in the pool . This is achieved by the call to ejbActivate() when getting associated with the remote stub and ejbPassivate() getting disassociated from the remote stub. Hope this explains it. Cheers