4 questions about stateful session bean,...

[Vichy Yao]

Hi experts,

1 A question about stateful session bean: A client invokes a stateful session bean, then the client times out. Will the stateful session bean instance will be removed by container? Or just will be passivated? Does it depend on different vender?

2 Please refer to point 1, if the instance of the stateful session bean is passivated after client timed out, how to get the stub of the same stateful session bean instance again for another client?

This question always makes me confused. For example, for browser/server mode, user do something but not commit on Monday, then he logout or HttpSession time out(30 minutes). On Tuesday, he login and he also hope he can see his last not-committed state and continue his operation. How to achieve it? A specilist told me using stateful session bean instead. But on Monday, if his stateful session bean instance is removed after client times out, how to get it again on Tuesday?

Please give me details about this case?

3 Another question about ejbRemove, if container decide to kill a passivated bean instance(stateful session bean or entity bean), I want to know, whether container invokes ejbRemove directly, or invokes ejbActivate then invokes ejbRemove?

4 How the container know the client times out? Where can I find the configuration? Or I can set it as NEVER time out.

[raphael Bereh]

Hi there,
I'm not an expert, but will try to give you a couple of answers :
Q 3 : Activation is about restoring the client conversational state (deserialisation ), so why would the container activate a bean just to kill it ? For instance , when a bean times out while passivated, it is removed without bean activated. I think the same apply here, to optimised the overhead of activating the bean.

Q4-Q1 : I don't think the container cares that much about the client. Instead the conatiner manages the Bean, and generally uses LRU algorithmes to see which bean has been inactive for a good while . The reason why the bean remainded inactive could be anything including client time-out. Eventually, you bean itself might time-out, and this is the configurable parameter on the container . see your server documentation on how to do that.

Q2 : The Handle is a serializable object. You could get the handle, serialise it to a file, transport you file to a different machine , deserialise it and use it to get a reference to the bean .

Any comments on my answers welcome.

[Vichy Yao]

Many thanks! I will try the handle.

I am preparing for SCWCD exam. I find a document in another website named 'SCBD Beta Exam Information and Mocks' prepared by Kathy and Bert, but many questions have no answers or detailed explains. Where can I get the full copy?

[ray chan]

response to question 3 (on the case entity bean):
container never calls ejbRemove() on an entity without a call on remove() from the client on the stub. Remember, ejbRemove on an entity means delete the line in the database, thing that the container will never do alone.
And if the bean is passivated at this moment (when the client calls remove() and the container wants to call ejbRemove()) the container will first activate it (remember, the bean entity might have relations to deal with (cascading ...)). So in case of entity bean the bean is first activated (when needed) and then deleted.
case session stateless bean : ejbRemove on stateless session bean is called by the container when he wants to reduce the size of the pool. (a call from the client on remove() does not mean a call on ejbRemove from the container (we're in case of stateless session bean, OK), the container simply says "and then what ...?")
case session statefull bean : if the bean times out, it gets a call on ejbRemove from the container before being removed. If it is passivated while it times out, it is sent to the garbage without being activated (nor receiving a call on ejbRemove()). If the bean throws a system exception it is sent to the gc without activation nor receiving a call on ejbRemove.

Have I forgot a case ??
kind regards.