I have a couple of questions about stateful session bean removal I hope somebody could help me with. Head First EJB shows four scenarios for what happens to a stateful session bean when the it dies, on pages 209-212: 1. Client calls remove() on an active (non-passivated) bean. 2. Bean times out while active. 3. Bean times out while passivated. 4. Bean throws a system exception. First of all, does number 2 imply that it may be possible to configure a container to immediately kill a stateful session bean rather than passivate it if the client is inactive for a certain time? Secondly, what happens if the client calls remove() while the bean is passivated()? Does ejbActivate() get called (page 204 of HFEJB says there is only one reason why ejbActivate() is called: the client called a business method; therefore I would guess that ejbActivate() cannot be called, and it doesn't seem to make sense to do so because the bean is about to die). And does ejbRemove() get called? My guess would be no, but the list of reasons why an ejbRemove() could get missed on page 215 does not include the client calling remove() while the bean is passivated. The state diagram doesn't seem to help with this question, as it shows the only ways out of the passivated state are timeout (which is not happening in this scenario) or ejbActivate(). This seems to suggest that the bean would receive ejbActivate() and ejbRemove() calls. Any help people can offer would be appreciated.
Hi Colin, Those are excellent questions. I hope I can clarify the situation a bit. In Weblogic, one can set the idle-timeout-seconds to a really low value (say 1) that would /in-effect/ cause the stateful session bean to be removed PDQ. In Websphere, one can se the timeout value (in the DD) to achieve the same effect as in Weblogic. I couldn't see anything about JBoss, but I'm sure it's there somewhere. However, if a stateful session bean is participating in a Tx, then it will *never* be removed until that Tx has completed (either commit or rollback) If I client calls remove() on a passivated bean, then the container will simple destroy it. It would be a waste of resource to load it back into memory (using some type of serialization-type process) just to then destroy it. So ejbRemove() doesn't get called nor does ejbActivate(). If a system exception is thrown (say out-of-memory) - uncheckable exceptions, then the bean moves to the Does Not Exist state and ejbRemove() is never called. -=david=-
Howdy, There are two little points I wanted to make here... 1) Passivation and timeout These two are really separated as far as the Container is concerned. Passivation is often determined by available resources, so you might want to configure your server by saying, "Don't passivate until you REALLY need to because RAM is low, but DO timeout after [some number] has passed without any activity..." So you could easily have scenarios where your beans can timeout, but they are in an active state as long as they're alive. You might want this for better performance. 2) ejbRemove() and passivation. This one is a little confusing because of the way the spec is written, but here it is:
* If the bean times out when passivated, the Container kills it without calling ejbRemove(). It makes an assumption that it isn't worth it, especially since it means this client has abandoned the service. * BUT... if the client calls remove(), the bean WILL be brought back out of passivation. The reason that this is confusing in the spec is because they use the word "business method", and the spec often uses "business methods" to include many of the methods exposed in the interaces including create and remove. So, when the client calls remove(), and the bean is passivated, the Container treats the call as a business method and wakes the bean up to run it. It assumes that there may be something specific to closing out this session with the client, and since the client is obviously still involved with the session. So, a bean will NOT be destroyed automatically when the client calls remove() and the bean is passivated. The bean will be activated, and then removed. This isn't really obvious in the spec, though, so it's easy to miss. ================= cheers, Kathy