Instance pooling
Raja Mani
Greenhorn
Posts: 26
jay roy
Ranch Hand
Posts: 145
Raja Mani
Greenhorn
Posts: 26
posted 10 years ago
Thanks Roy,
As per the book the A B & C are correct and following is the explanation given
Stateful session beans cannot be pooled because the instances need to maintain state and thus cannot be swapped between users. Hence, choice D is incorrect. Apart from this, stateless session beans can be pooled because there is no need for state maintenance. Entity beans can also be pooled because their state information is always backed up in the persistent store and can be retrieved back. Therefore,
choices A, B, and C are correct.
As per the book the A B & C are correct and following is the explanation given
Stateful session beans cannot be pooled because the instances need to maintain state and thus cannot be swapped between users. Hence, choice D is incorrect. Apart from this, stateless session beans can be pooled because there is no need for state maintenance. Entity beans can also be pooled because their state information is always backed up in the persistent store and can be retrieved back. Therefore,
choices A, B, and C are correct.
Raja Mani
Greenhorn
Posts: 26
jay roy
Ranch Hand
Posts: 145
posted 10 years ago
>>>>If stateful session bean does'nt support instance pooling then what is the need for the ejbActive() and ejbPassive()methods.
ok.good question. Here is what i feel.
"Pooling of beans" and "activation/passivation" are two different things.
when stateful session bean is not being used it it sent to passivate state . when this happens ,basically the bean is moved from local memory to a secondary storage. When client invokes the bean again , the bean is moved from passivate state to ready state.That is the main concept of Activation/Passivation.
This process of Activation/passivation is no way related to pooling.
Pooling happens for stateless session beans and entity beans where there is a "pooled" state.
hope i made it clear
J
ok.good question. Here is what i feel.
"Pooling of beans" and "activation/passivation" are two different things.
when stateful session bean is not being used it it sent to passivate state . when this happens ,basically the bean is moved from local memory to a secondary storage. When client invokes the bean again , the bean is moved from passivate state to ready state.That is the main concept of Activation/Passivation.
This process of Activation/passivation is no way related to pooling.
Pooling happens for stateless session beans and entity beans where there is a "pooled" state.
hope i made it clear
J
jay roy
Ranch Hand
Posts: 145
posted 10 years ago
however , please note that my above comment is valid ONLY for stateful session beans
But for entity beans there is a relation between pooling and activation/passivation: ejbPassivate() sends the bean from ready state to pool state, and ejb activate does vice- versa.
and for stateless session beans, there is no concept of activation/passivation.
But for entity beans there is a relation between pooling and activation/passivation: ejbPassivate() sends the bean from ready state to pool state, and ejb activate does vice- versa.
and for stateless session beans, there is no concept of activation/passivation.
Durgaprasad Guduguntla
Ranch Hand
Posts: 99
posted 10 years ago
In SFSB, the container controls the activation and passivation processes. The container invokes passivation process depending upon the instance cache of the SFSB. Though there is no instance pooling for SFSBs, there is a configuration of instance-cache (in a vendor specific deployment descriptor) in order to indirectly control the activation and passivation process.
In the above case the container internally puts the SFSB instances in the cache and assign them to the clients till they reach maximum limit of 50 concurrent clients. If there is a 51st client tends to create SFSB, then the container looks for idle beans in the cache and passivate them. Thus if the concurrent clients are more than the instance-cache, there is a chance of passivation and activation quite often which is an expensive serialization process and thereby degrade the performance of application. Hence SFSBs are fine-tuned by configuring optimal instance-cache size to improve the performance.
In the above case the container internally puts the SFSB instances in the cache and assign them to the clients till they reach maximum limit of 50 concurrent clients. If there is a 51st client tends to create SFSB, then the container looks for idle beans in the cache and passivate them. Thus if the concurrent clients are more than the instance-cache, there is a chance of passivation and activation quite often which is an expensive serialization process and thereby degrade the performance of application. Hence SFSBs are fine-tuned by configuring optimal instance-cache size to improve the performance.
Thanks,<br />Durgaprasad<br />SCJP1.4, SCWCD1.4, SCBCD1.3,<br />SCEA
posted 10 years ago
Sorry for hijacking this thread. 
Why does a SFSB have ejbActivate and ejbPassivate?
That's a good question. It's one that bugs alot of people.
One thing to bear in mind with regards to EJBs, is that once upon a time, there were only SLSBs, no CMPs, no BMPs, no SFSBs and no MDBs. The spec has grown from SLSBs, and sometimes it looks like a square peg has been stuck into a round hole. There are many things in the spec that, from a very philisophical standpoint, probably shouldn't be in there, although we can easily rationalize away their existence.
Many people like Spring and Hibernate becuase of their elegance. Some of the eveolution of the EJB spec hasn't been all that 'elegant.'
Just an opinion.
-Cameron McKenzie
Why does a SFSB have ejbActivate and ejbPassivate?
That's a good question. It's one that bugs alot of people.
One thing to bear in mind with regards to EJBs, is that once upon a time, there were only SLSBs, no CMPs, no BMPs, no SFSBs and no MDBs. The spec has grown from SLSBs, and sometimes it looks like a square peg has been stuck into a round hole. There are many things in the spec that, from a very philisophical standpoint, probably shouldn't be in there, although we can easily rationalize away their existence.
Many people like Spring and Hibernate becuase of their elegance. Some of the eveolution of the EJB spec hasn't been all that 'elegant.'
Just an opinion.
-Cameron McKenzie
Raja Mani
Greenhorn
Posts: 26
posted 10 years ago
Hi Jay/Durgaprasad,
Thanks, But still I have certain doubts on "Instance pooling can'nt be performed on StateFull Session bean "
1. If instance pooling is not supported for SFSB then how it can handle concurrency i.e., mutliple clients at any given point of time?. Then its not scalable.
2. Suppose if SFSB can handles multiple clients at any given point of time without instance pooling then in that case it has to maintain the passivated data for every client separately (if there any concurrent access happens lets say 5 clients try to access the same SFSB at a given point of time) and activate the bean according to the client invocation. That means it has to maintain the single bean instance (as SFSB doen�nt support instance pooling) and swap between the client by using the activate and passivate methods. Otherwise how this is handled?.
If it is possible with single bean instance to swap between multiple clients, why can�t it happen with multiple instance, as at any point of time the bean instance is neutral and based the client that invoke the bean its appropriate passivated data will be loaded into it. So what stops SFSB from instance pooling?.
Also as per Duragaprasad�s statement instance pooling for SFSB is container specific also I read the same in some other form. But still I not clear. Correct me if iam wrong.
Thanks, But still I have certain doubts on "Instance pooling can'nt be performed on StateFull Session bean "
1. If instance pooling is not supported for SFSB then how it can handle concurrency i.e., mutliple clients at any given point of time?. Then its not scalable.
2. Suppose if SFSB can handles multiple clients at any given point of time without instance pooling then in that case it has to maintain the passivated data for every client separately (if there any concurrent access happens lets say 5 clients try to access the same SFSB at a given point of time) and activate the bean according to the client invocation. That means it has to maintain the single bean instance (as SFSB doen�nt support instance pooling) and swap between the client by using the activate and passivate methods. Otherwise how this is handled?.
If it is possible with single bean instance to swap between multiple clients, why can�t it happen with multiple instance, as at any point of time the bean instance is neutral and based the client that invoke the bean its appropriate passivated data will be loaded into it. So what stops SFSB from instance pooling?.
Also as per Duragaprasad�s statement instance pooling for SFSB is container specific also I read the same in some other form. But still I not clear. Correct me if iam wrong.
jay roy
Ranch Hand
Posts: 145
posted 10 years ago
Raja,
I think Durgaprasad nicely explained how concurrent users can access the stateful session bean ( by using the concept of instance cache)
Please go through his explanation once again, it contains answers to most of your questions.
Definetely stateful session beans have scalability problems and that is why most people prefer stateless beans over stateful session beans.
Also, we have to remember that we must follow the EJB specification guidelines. SUN wanted to prevent users from setting bean pooling for stateful sesssion bean, so we really cannot do anything.
[ December 29, 2006: Message edited by: jay roy ]
I think Durgaprasad nicely explained how concurrent users can access the stateful session bean ( by using the concept of instance cache)
Please go through his explanation once again, it contains answers to most of your questions.
Definetely stateful session beans have scalability problems and that is why most people prefer stateless beans over stateful session beans.
Also, we have to remember that we must follow the EJB specification guidelines. SUN wanted to prevent users from setting bean pooling for stateful sesssion bean, so we really cannot do anything.
[ December 29, 2006: Message edited by: jay roy ]
jay roy
Ranch Hand
Posts: 145
Durgaprasad Guduguntla
Ranch Hand
Posts: 99
posted 10 years ago
After the cache limit is reached, the container attempts to find any idle bean from the cache eligible for passivation and if it don't find one, there won't be any passivation. At this stage, I think it still allows creation of new SFSBs. Further the instance-cache is vendor-specific and not a J2EE standard. If you would like to know in-depth information on this, refer to the following links:
http://edocs.bea.com/wls/docs81/ejb/session.html#1121360
http://edocs.bea.com/wls/docs81/perform/EJBTuning.html#1135433
Originally posted by jay roy:
If all the instances in instance-cache have been used up and there are no instances available, what happens when more concurrent users try
to access the bean and there are no instances avaialble. Are they just turned away?
After the cache limit is reached, the container attempts to find any idle bean from the cache eligible for passivation and if it don't find one, there won't be any passivation. At this stage, I think it still allows creation of new SFSBs. Further the instance-cache is vendor-specific and not a J2EE standard. If you would like to know in-depth information on this, refer to the following links:
http://edocs.bea.com/wls/docs81/ejb/session.html#1121360
http://edocs.bea.com/wls/docs81/perform/EJBTuning.html#1135433
Thanks,<br />Durgaprasad<br />SCJP1.4, SCWCD1.4, SCBCD1.3,<br />SCEA
Raja Mani
Greenhorn
Posts: 26
ManojKumar Unnikrishnan
Ranch Hand
Posts: 32
| With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |