Originally posted by manish ahuja:
Hi
1) If a stateful bean is in a passivated state & say the client invokes remove will the ejbremove() method be invoked for the same
ejbRemove() can only be called by the container on a stateful session bean in the 'method ready' state. The only way a stateful session bean can pass from the 'passivated' state to the 'does not exist' state is if it times-out. I suppose that the way to handle this is vendor-specific, but I suppose that a way for the container could be: when a client invokes remove on a stateful session bean's EJBObject stub, the container will first invoke ejbActivate() on the bean, therefore re-assigning the state persisted during passivation, and then will invoke ejbRemove() on the same.
2) Say if I just have one create no args method in my stateful bean how will the state management work or is it imperative to have a create method with args in case of stateful beans
Why are you interested in constructors? A Stateful session bean must have at least one-no-argument create method, but if a create method with argument exists it's not mandatory (I'm not sure but it should be like that!). The bean's state is saved by the container in a sort of secondary storage, which might mean serialization, or it might not (this is vendor-specific). The only thing the container-vendor must ensure is that something that behaves like serialization will save the stateful session bean during passivation (and therefore will reassign the correct state during activation). Our responsibility as bean-developers is to guarantee that all the instance variables of the stateful session bean will be ready for passivation; in other words these should be a reference to:
1) A Serializable object
2) A primitive datatype
3) A null object
4) A collection or array of Serializable objects or primitive datatypes
5) A JNDI local context
6) A SessionContext
7) A Resource Manager
8) A Remote EJBObject or EJBHome
Hope this will help,
Marco
Marco Tedone<br />SCJP1.4,SCJP5,SCBCD,SCWCD