• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Serialization and ejbPassivate question

 
Eduard Manas
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following is a 'valid' answer from a mock test (Whizlabs):
"All non-transient and non-serializable fields of a Stateful Session Bean have to be set to null in the ejbPassivate() method"
The reason why I disagree with this statement is because if there are non-trasient objects they MUST be serializable, otherwise a runtime exception is thrown. The fact that those objects are null does not avoid throwing the exception (...or does it?)
Can anyone help on this?
Thanks
 
Darryl A. J. Staflund
Ranch Hand
Posts: 314
2
Android Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's what it reads in Monson-Haefel's book (pp. 360-1):
"When a bean is about to be passivated, it's ejbPassivate () method is invoked, alerting the bean instance that it is about to enter the Passivated state. At this time, the bean instance should close any open resources and set all nontransient, nonserializable fields to null. This will prevent problems from occurring when the bean is serialized. Transient fields will simply be ignored.
"A bean's conversational state may consist of only primitive values, objects that are serializble, and the following special types:
[EJB 2.0 and 1.1. SessionContext, EJBHome, EJBHome, EJBObject, UserTransaction, Context]
[EJB 2.0 only. EJBLocalHome, EJBLocalObject, References to managed resource factories]
"The types in this list (and their subtypes_ are handled specially by the passivation mechanism. They do not need to be serializable; they will be maintained through passivation and restored automatically to the bean instance when it is activated.
...
"Except for the special types listed earlier, all fields that are nontransient and nonserializable must be set to null before the instance is passivated or else the container will destroy the bean instance, making it unavailable for continued use by the client.
Cheers,
Darryl
 
Darryl A. J. Staflund
Ranch Hand
Posts: 314
2
Android Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi again,
The reason why I disagree with this statement is because if there are non-trasient objects they MUST be serializable, otherwise a runtime exception is thrown.
I didn't read your original post closely enough so I missed this. As I understand Java, the properties of a Java class can be serializable, transient, or non-serializable. If your class you are attempting to passivate implements and or declares some properties of a type that implements these methods, than can explicitly be made non-serializable by having these methods throw for reasons of security or whatever.
Darryl
 
Eduard Manas
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your help Darryl,
I have been doing a little bit more of research on the matter and I have found the following that fully backs what you say.
I have found it in the EJB2.0 spec (section 7.4 conversational state), which it's like the Bible for all us preparing the SCEA exam.

The Bean Provider is required to ensure that the ejbPassivate method leaves the instance fields
ready to be serialized by the Container. The objects that are assigned to the instance�s non-transient fields after the ejbPassivate method completes must be one of the following:
� A serializable object.
� A null.
� An enterprise bean�s remote interface reference, even if the stub class is not serializable.
� An enterprise bean�s remote home interface reference, even if the stub class is not serializable.
� An entity bean�s local interface reference, even if it is not serializable.
� An entity bean�s local home interface reference, even if it is not serializable.
� A reference to the SessionContext object, even if it is not serializable.
� A reference to the environment naming context (that is, the java:comp/env JNDI context) or any of its subcontexts.
� A reference to the UserTransaction interface.
� A reference to a resource manager connection factory.


I got confused here between 'standard' Java serialization and the bean serialization carried out by containers. After reading this I conclude that all containers must override the readObject()/writeObject() methods to provide object serialization that must follow the above EJB2.0 requirements.
Thanks again
Eduard
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic