Stateless session beans' scalibility

[Ko Ko Naing]

On page 103 of the HF EJB, it says...

Clients don't share EJBObjects, but the same bean can service multiple EJBObjects. Just npt at the same time.........

Does it mean that if two EJBObjects ask for a certain type of stateless session beans at the same time, there will be two beans coming up from the pool and service the EJBObjects? Then the container will create two instances of that bean and let'em service to the EJBObjects...
It seems like everything is up to the container about the stateless session beans pool and what we just need to know, related to the exam, is that the same bean can service multiple EBObjects, if they are one after another... And if multiple EJBObjects ask for the service at the same time, there will be beans coming up from the pool as much as EJBObjects, in order to cover the services...
Correct me, if I am wrong... I'm rushing on my way to SCBCD...

[Seema Manivannan]

hi Ko Ko
You are right. We do not need a bean instance per client, but we do need a bean to service every business method which is currently excecuting. Also note that a bean gets actually associated with the EJB Object only when a business method gets called and not when the client calls the create() method on the bean.
Thanks
Seema

[Ko Ko Naing]

Thank you for the confirmation, seema... It's good that what I understand is correct...

[Roger Chung-Wee]

Does it mean that if two EJBObjects ask for a certain type of stateless session beans at the same time, there will be two beans coming up from the pool and service the EJBObjects?

The container is multi-threaded, so this is what happens. However, if there are not enough beans in the pool, I would think that the container will have to put the request on hold until a bean instance is free.

[Ko Ko Naing]

Originally posted by Roger Chung-Wee:

The container is multi-threaded, so this is what happens. However, if there are not enough beans in the pool, I would think that the container will have to put the request on hold until a bean instance is free.

why doesn't the container create a bean for that client? Will the container let the request to wait? What if other requests take a long time? If it is so, there will be a great overhead...
Can anyone give an explanation on it? Thanks...

[Anushe Khan]

quote koko
why doesn't the container create a bean for that client? Will the container let the request to wait? What if other requests take a long time? If it is so, there will be a great overhead
-------------
Container can either create some beans and place them in a pool or the container might make just-in-time beans.
HF EJB ---page102

[Valentin Crettaz]

The section 7.5.6 of the EJB specification states

Clients are not allowed to make concurrent calls to a stateful session object. If a client-invoked business method is in progress on an instance when another client-invoked call, from the same or different client, arrives at the same instance of a stateful session bean class, the container may throw the java.rmi.RemoteException to the second client, if the client is a remote client, or the javax.ejb.EJBException, if the client is a local client. This restriction does not apply to a stateless session bean because the container routes each request to a different instance of the session bean class.

Then further in section 7.8:

A container only needs to retain the number of instances required to service the current client load. Due to client "think time", this number is typically much smaller than the number of active clients. Passivation is not needed for stateless sessions. The container creates another stateless session bean instance if one is needed to handle an increase in client work load. If a stateless session bean is not needed to handle the current client work load, the container can destroy it.

I guess this is pretty self-explanatory

[Roger Chung-Wee]

why doesn't the container create a bean for that client?

Typically, the container will create a pool for each stateless, entity and message-driven bean class. The pool has a size limit. For example, you set the pool size in WebLogic in the weblogic-ejb-jar.xml deployment descriptor file like this.
<max-beans-in-free-pool>1000</max-beans-in-free-pool>
It is possible to envisage a scenario whereby an application with several thousand users could cause all the bean instances to be simultaneously in use. This is why I suggested that the container would have to put some requests on hold.

[Ko Ko Naing]

So, Roger, do u mean we have to set the maximum size of the pool, according to the visitors number of the site? Well then, it'll be a job for bean deployer... Isn't it?
But I guess, for the exam, we have to understand what the spec mandated for the container vendors and I think we do need to answer the questions in the exam according to the spec...