JSP Sessions,Attributes, and Deep Copy

[Berlin Brown]

Assume, I have a bean, serializable, set/get.

Assume one of the properties is just an Object

Object a = null;

Is there some limit to how far I can store objects before they get
lost. For example. Can I have a Map of Arrays of Maps of Vectors or
Lists of Arrays? Will all the values get copied if I put all these on
a session variable.

setA(Object b);
Object getA();

bean = new Bean();
bean.setA(obj);

obj = new ArrayList();
obj.add("Something");

Map m = new Map();
m.put(new List().add("SomethingElse");
obj.add(m);

Is there some limit to the stuff above before I lose values?

session.setAttribute(bean);

If I do session.getAttribute();
will all the values be there?

Object o = (Object)session.getAttribute("blah");
That is a pretty good deep copy?

 

[John C. Bollinger]

Assume, I have a bean, serializable, set/get.

Assume one of the properties is just an Object

Object a = null;

Then your bean is effectively _not_ serializable (unless "a" is _always_
null) because it is possible to put a reference to a non-serializable
object in "a". You could avoid this problem by using type Serializable
instead of type Object.

Is there some limit to how far I can store objects before they get
lost. For example. Can I have a Map of Arrays of Maps of Vectors or
Lists of Arrays? Will all the values get copied if I put all these on
a session variable.

First, serialization. Java's standard serialization mechanism follows
the whole graph of an object and all other objects reachable from it via
a chain of non-transient references. It outputs the whole thing in a
form that can be wholly reconstituted later, provided that all objects
in the graph are in fact Serializable. If any non-serializable objects
are encountered then the whole serialization fails.

Second, session attributes. Setting an object as a session attribute
does not cause it to be copied at all. It just causes the session to
track a reference to the (same) object in such a way that it can later
be retrieved via the assigned name. Now, it _is_ possible that the
servlet container in some circumstances might serialize idle sessions
(with their attributes), and later deserialize them when they are needed
again. This is an entirely different issue, but a good reason to not
set non-serializable objects as session attributes if you want your
application to be portable.

setA(Object b);
Object getA();

bean = new Bean();
bean.setA(obj);

obj = new ArrayList();
obj.add("Something");

That won't compile if the type of "obj" is Object. You would need to
downcast at least as far as Collection.

Map m = new Map();
m.put(new List().add("SomethingElse");
obj.add(m);

Is there some limit to the stuff above before I lose values?

No, no limit. You will never mysteriously lose values from a deeply
nested data structure. Your program might cause values to disappear in
one way or another, possibly contrary to what you expect, but that's
different.

session.setAttribute(bean);

If I do session.getAttribute();
will all the values be there?

Yes. All you do there is obtain another copy of the reference to the
same object (even if the set and get happen during the processing of
different requests (in the same session)).

Object o = (Object)session.getAttribute("blah");

The cast to Object is unnecessary.

That is a pretty good deep copy?

No, it's not a copy at all. It gets back a reference to the object
assigned as session attribute "blah". The same object.

As an aside, a serialization / deserialization cycle _is_ a way to
perform a deep copy, provided that the object is serializable, but there
are some caveats (that I won't go into at the moment).


John Bollinger
(e-mail address removed)

 

[Berlin Brown]

I have been following your posts of the years, you know what you are
talking about, thanks.