Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Serializable (?) Objects associated to a session

 
Colin Fletcher
Ranch Hand
Posts: 200
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am preparing for the WCD (I have been for a while now but a baby, moving to a new house, and new job have delayed my progress).

I am reading HFSJ and in the mock exam on page 269, Question 12 "Which statements about HttpSession objects in distributed environments are true?"
item D: When a session is moved from one JVM to another, attribute values that implement java.io.Serializable will be transferred to the new JVM". Item D is marked as one of the answers for this question, which I did not select.

According to an excerpt from the spec, below, implementing Serializable does not guarantee the object will retain its values in the new JVM. The way I am thinking about Serialization: Objects that implement Serializable may be transferred to the new JVM, however this is container dependent.

Did I miss something?

From the 2.4 spec:

The distributed servlet container must support the mechanism necessary for
migrating objects that implement Serializable. Distributed servlet containers
that are part of a J2EE implementation must support the mechanism necessary for
migrating other J2EE objects.
These restrictions mean that the Developer is ensured that there are no
additional concurrency issues beyond those encountered in a non-distributed
container.
The Container Provider can ensure scalability and quality of service features
like load-balancing and failover by having the ability to move a session object,
and its contents, from any active node of the distributed system to a different node
of the system.
If distributed containers persist or migrate sessions to provide quality of
service features, they are not restricted to using the native JVM Serialization
mechanism for serializing HttpSessions and their attributes. Developers are not
guaranteed that containers will call readObject and writeObject methods on
session attributes if they implement them, but are guaranteed that the
Serializable closure of their attributes will be preserved.
[ February 28, 2005: Message edited by: Colin Fletcher ]
 
muthulingam Jayakanthan
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Colin,

What is HFSJ. Can somebody help me to get these and relavant mock exam.
 
P. Dunn
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Colin Fletcher:
> ...attribute values that implement java.io.Serializable will be transferred to the new JVM.
>[container] does not guarantee the object will retain its values in the new JVM.
>Spec:
Developers are not guaranteed that containers will call readObject and writeObject methods on session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved.

Although I'm disturbed by this news, apparently the difference (based on the semantics of your quotes) is that the object is transferred, but none of its internal property values are guaranteed to be transferred. I'll attempt to reuse the words of the question: the "attribute value" (attribute object) is transferred, but any property of that "attribute value" is not guaranteed to retain it's (the property's) value.

If I am correct, the attribute class should implement HttpSessionBindingListener to solve this.

BTW Who came up with the phrase "Serializable closure"? That's awful.
[ March 02, 2005: Message edited by: P. Dunn ]
 
Colin Fletcher
Ranch Hand
Posts: 200
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From a logical point of view it would seem strange for the web container to not honor the Serializable interface.

The HttpSessionActivationListener interface is used to notify objects when moving JVMs.

Thank you :-)
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I understand is the following:

"The distributed servlet container must support the mechanism necessary for
migrating objects that implement Serializable." ===> This is clear.

"...[distributed containers] are not restricted to using the native JVM Serialization mechanism for serializing HttpSessions and their attributes." ===> This DOESN'T mean that the attributes will not conserve their values; it ONLY MEANS that the readObject and writeObject methods on these attributes could not be called, since the container could use another way to carry out the serialization.

What do you think?
[ March 03, 2005: Message edited by: Jose Esteban ]
 
Colin Fletcher
Ranch Hand
Posts: 200
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jose, I think the spec is very ambiguous. Using the Activation Listener interface seems like re-inventing the serialization wheel.

These two quotes seem to contradict each other, hence the ambiguity.

The distributed servlet container must support the mechanism necessary for migrating objects that implement Serializable.

Developers are not guaranteed that containers will call readObject and writeObject methods on session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved.



If the intent is when transferring a session attribute from one jvm to another jvm, use of the Serializable interface will be used. When the attribute is stored to permanent storage, Activation Listener interface is used.... that would be clear. However I am not convinced.

Great discussion going here :-)
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Colin, I don't think the spec is ambiguous. I'll try to resume what I understand:

1) If you have an attribute that implements the Serializable interface, you are telling the container that you are interested in migrating it to another JVM if it is necessary. How the container carries out the migration is not your business. But the "Serializable closure" (i.e., the value) of the attribute will be preserved in the migration. In this case, you don't need to use an Activation Listener at all. All happens automatically. Easy.

2) If you have an attribute that DOESN'T implement the Serializable interface, it should implement HtttpSessionActivationListener (and its methods sessionDidActivate() and sessionWillPassivate()) to do the things manually, because the container will not migrate the attribute.
 
Colin Fletcher
Ranch Hand
Posts: 200
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So if that is the case, how do you explain this from the spec?

Developers are not guaranteed that containers will call readObject and writeObject methods on session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved.
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's the key point and it's what I told you in my first post:

"...[distributed containers] are not restricted to using the native JVM Serialization mechanism for serializing HttpSessions and their attributes." ===> This doesn't mean that the attributes will not conserve their values; it ONLY MEANS that the readObject and writeObject methods on these attributes could not be called, since **** THE CONTAINER COULD USE ANOTHER WAY (not serialization) TO CARRY OUT THE MIGRATION of the serializable attributes ****.

[ March 03, 2005: Message edited by: Jose Esteban ]
[ March 03, 2005: Message edited by: Jose Esteban ]
 
Colin Fletcher
Ranch Hand
Posts: 200
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jose, I get what you are saying.

If a web container needed to migrate a session to another jvm, and a session attribute only implemented the serializable interface... the results are not predictable because the web container could choose to serialize the object in a different way, hence the HttpSessioniActivationListener interface.

The way I handled this was to implement both Serializable and httpSessionActivationLitener interface... the listener just called read/write object..
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry Colin, but I think that you still don't get what I'm saying.

The results are predictable. I mean:

1) If the attribute is serializable, its migration is carried out by the container automatically, although the container could not use Serialization in the process of migration (it is not our business what method the container uses; every container could use a different method).

2) If the attribute is not serializable, the container doesn't migrate it. If you what the attribute to migrate, then you�ll have to do it yourself (probably, using an Activation Listener).

Originally posted by Colin Fletcher:

The way I handled this was to implement both Serializable and httpSessionActivationLitener interface... the listener just called read/write object..


This isn't a solution. Some attributes are not serializable, for example, because they have an instance variable that is not serializable. And if the attribute is serializable, you don't need to implement HttpSessionActivationLitener since it doesn't do any good; it is totally superfluous.
[ March 03, 2005: Message edited by: Jose Esteban ]
 
Colin Fletcher
Ranch Hand
Posts: 200
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Got it. :-) thanks
 
P. Dunn
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jose Esteban:

This DOESN'T mean that the attributes will not conserve their values; it ONLY MEANS that the readObject and writeObject methods on these attributes could not be called.


Yes, after a night's sleep and looking back at HFS, I agree. The the implication is the container transfers the attribute state in a way of its choosing.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic