The following conversational state will be passivated and restored correctly by the container and the bean provider does not have to do anything.
I) A reference to an enterprise bean�s business interface.
Questions --------- i) The above statement applies to session beans, because MDB and entity beans do not have business interface. Is this correct?
ii) If my stateful session bean has a reference to other session bean instance [Logically a stateless session bean], For example the statefull session bean might be using services from other stateless session beans to accomplish its business. These references will be automatically restored by the container.
The thing that i am trying to say is Statefull Session Bean has
Here HelloUser is the Stateless "WelcomeBean" 's remote business interface. [MDB, Entity beans do not have such business interface]. When the bean is passivated and activated again.
More Questions -------------- a) Will bean will point to WelcomeBean instance or will it be lost and have null? b) If WelcomeBean was a statefull session bean, will its instance fields be restored , provided they one of the EJB 3.0 Core Specification 4.2.1 Instance Passivation and Conversational State defined members ?
II) A reference to an enterprise bean�s remote interface, even if the stub class is not serializable. Questions --------- i) Does remote interface mean, Remote business interface defined with @Remote annotation ? ii) What does it mean when the specification says "Stub class is not serializable" ? iii) A stateful sesion bean will have a reference to enterprise beans that are not in this container using Remote interface reference. Is this statement correct ? Does the Stub class refers to the instance of such beans [session bean] ? Does "Stub class is not serializable" means that the class is not implementing "java.io.Serializable" interface?
In the above case : One thing is sure that the instance has to be moved to secondary storage during passivation. Now if that class is not implementing java.io.Serializable iterface then Container can use its own technique to achive Passivation.
Wow i just realized, was this the reason now that beans are not required to implement java.io.Serializable interface ? And since the above rule was removed the sesison bean will be passivated using any technique and not Java Serialization technique that was used when bean were forced to implement java.io.Serializable interface prior to EJB 3.0.If all my above statements are correct then i will say "Good improvisation by EJB Container" i) Container is not tied with Java Serialization techinique.Container can now use any technique. ii) Bean provider are freed from forcing beans implement java.io.Serializable interface. III) A reference to an enterprise bean�s remote home interface, even if the stub class is not serializable.
In case of EJB 3.0 there is no concept of home interface [In fact i don';t even know what does home mean?]