Can anybody tell me, if N number of clients accessing the ejb stateless session bean then how many instances will be created???
The number of SLSB instances doesn�t depend upon the number of clients accessing the ejb. It has everything to do with the way the pool is configured. Most containers provide special deployment descriptor tags that like initial-beans-in-free-pool and max-beans-in-free-pool. The way it works is pretty intuitive: when starting up, the server automatically creates exactly initial-beans-in-free-pool beans in the pool. As the number of client requests grows, it will increase the pool up to max-beans-in-free-pool. If a client needs to access the bean and no instances are available the transaction will block until either a bean instance becomes available or the transaction times out.
whether it will for different bean like statless, stateful, entity bean,
Well for SFSB there is no pooling involved and in theory the number of SFSB should be equal with the number of clients accessing them. That�s not always the case because some containers might chose to take a step further and cache them. Weblogic for example maintains a cache of SFSBs and the server allows configuring the cache in a similar (but not at all identical) way the SLSB free pool is configured. The cache is internally managed using either an LRU or NRU algorithm for passivating the beans. Entity beans on the other hand are even more complicated because the container always pools the bean instances (as per EJB specs) but it can also cache them. The difference is that the beans in the pool are not associated with any clients, while beans in the cache have always an identity (a primary key) and are associated with clients. The server allow configuring the max-beans-in-cache. So as you can see there is no straight answer to how many bean instances the container creates. It could be quite different depending upon the type of container or the type of settings allowed. Regards.
I think, therefore I exist -- Rene Descartes
Joined: Feb 23, 2005
I found this question in one site? when i compare this with your reply i got confused.... here the question..
The EJB container implements the EJBHome and EJBObject classes. For every request from a unique client, does the container create a separate instance of the generated EJBHome and EJBObject classes?
A: The EJB container maintains an instance pool. The container uses these instances for the EJB Home reference irrespective of the client request. while refering the EJB Object classes the container creates a separate instance for each client request. The instance pool maintainence is up to the implementation of the container. If the container provides one, it is available otherwise it is not mandatory for the provider to implement it. Having said that, yes most of the container providers implement the pooling functionality to increase the performance of the application server. The way it is implemented is again up to the implementer.
it means that if you use SLSB it wont create a instance for every client in EJBObject , but for SFSB it will create a insatnce for every client in EJBOject...
am i right...
Joined: Feb 17, 2005
So you want to understand the relationship between the EJBObject/EJBHome and the bean instances... Well this is little bit different than the question you initially asked, which is mostly about the way beans are instance pooled. Well I hope you understand now that the first step one must do in order to get the right answer is to ask the right question :-) In my opinion you have the right to be confused, because the answer you got is not very clear. The answer is also probably vendor specific, but most of the containers maintain a one-to-many relationship between the home object and the bean instances. The home object uses bean instances from the pool in order to serve bean�s life cycle methods like finders (here the analogy with the pool) and is designed thread safe. The relationship between the EJBObject and the bean instances could be either one-to-many, where each such object is multithreaded, or many-to-many (one EJBOject per client) and in this case the EJBObject is single threaded. Either way the answer to your question seems to be the same: the container creates only one instance of the EJBHome and EJBObject to service requests coming from the same client. Regards.
Every client is given a remote handle to its EJBObject, so there is one EJBObject per client. Well, maybe! You see, the EJBObject is something which represents the client's view of an EJB. It is certainly possible that the container will create an EJBObject per client, but that would be inefficient. At the other end of the efficiency scale, it is possible for the container to create only one physical EJBObject, but give each client the impression that it is interacting with its own EJBObject - a virtual EJBObject you could say.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Joined: Feb 23, 2005
Hi Valentin and Roger, Thanks for your reply. Now i am very clear about the EJB bean and Home ,Remote instances.