aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Doubt about number of instances?? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Doubt about number of instances??" Watch "Doubt about number of instances??" New topic
Author

Doubt about number of instances??

gopal kishan
Ranch Hand

Joined: Feb 23, 2005
Posts: 99
Hi All,

Can anybody tell me, if N number of clients accessing the ejb stateless session bean then how many instances will be created???

whether it will for different bean like statless, stateful, entity bean,

please clarify...


thanks in advance
Gopal
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 31079
    
163

Gopal,
It depends on what you set your pool size settings to be. Same for stateful session beans.

For entity beans, it depends on what data they access.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
gopal kishan
Ranch Hand

Joined: Feb 23, 2005
Posts: 99
HI,

I am not clear with that.what you say is if 10 clients accesing the statless/ stateful sessio bean, if will take the instances from the pool, am i right.

please clarify.

thanks in advance
Gopal
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Gopal,


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
gopal kishan
Ranch Hand

Joined: Feb 23, 2005
Posts: 99
Hi Valentin,

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...

please clarify.....

Gopal
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi,

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.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
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
gopal kishan
Ranch Hand

Joined: Feb 23, 2005
Posts: 99
Hi Valentin and Roger,
Thanks for your reply. Now i am very clear about the EJB bean and Home ,Remote instances.

thanks for your patience and for sending reply.

regards
Gopal.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Doubt about number of instances??