Question about Session object

[Gregg Bolinger]

I can't believe I am having to ask this question as much as I have been doing J2EE, but since there is no such thing as a dumb question on Javaranch....

If I store an object in the session and then later retrieve that object, if I make changes to the object, do I need to put it back in the session or am I working with a reference to the session object?

Thanks.

[Bear Bibeault]

You are working with a reference. No need to put it back. Think of the attributes as Map entries.
[ February 11, 2005: Message edited by: Bear Bibeault ]

[Gregg Bolinger]

Originally posted by Bear Bibeault:
You are working with a reference. No need to put it back. Think of the attributes as Map entries.

[ February 11, 2005: Message edited by: Bear Bibeault ]

Perfect, thanks. That saves me a bit of work.

[James Carman]

Originally posted by Bear Bibeault:
You are working with a reference. No need to put it back. Think of the attributes as Map entries.

[ February 11, 2005: Message edited by: Bear Bibeault ]

Better yet, think of it as if you are coding in Java! All objects are passed by reference in Java! :-)

[Jeroen Wenting]

We all have our DOH! moments Greg, nothing to be ashamed of.
Sometime last year I was looking desperately for why something I set in one JSP suddenly started causing errors in another.
Wasn't until a few days later that I realised I used the same session variable in 2 JSPs/servlets to hold quite different things...

[Stan James]

Does anyone have team practices to avoid what Jeroen described? A list of variable names in use, naming conventions? Seems like a very easy and probably very common mistake.

[Ben Souther]

I generally bind only one object to the user's session: 'userBean'.
Anything I need to store in session becomes a property of that object.

If while working on component 'B', I decide to add variable 'x' to session, but have already done so for component 'A', I would quickly be reminded as soon as I tried to add property 'x' to the userBean object.

I never thought of it as a wrapper for the session, but I guess that's what it is, sort of, in reverse -- a more strongly typed session object. It wasn't written for this purpose.
I wrote it to avoid making repeated getAttribute calls with all the casting invloved (IOW: to save typing).

[ February 12, 2005: Message edited by: Ben Souther ]


You could enforce this policy in your code during development by using HttpSessionAttributeListener, Class.isInstance(Object), and an assertion to test any object being bound to the session to insure that it is an instance of yourpackage.userBean.
[ February 12, 2005: Message edited by: Ben Souther ]

[Gregg Bolinger]

I use an object called Visit which stores most of my session variables. So I only need to get the visit object to get everything else. Visit represents a users session on my web app. So for my current app I have objects set in Visit like user, currrentIssue, etc. I never have liked the idea of have 20 different objects seperatly in the session. I also use a constant I use when saving and retrieving my visit object so I don't have to wonder a year from now what I called it in the session and have to dig through my code. So I would do something like:

Visit visit = (Visit)session.getAttribute(Constants.VISIT_KEY);

[ February 12, 2005: Message edited by: Gregg Bolinger ]

[Gregg Bolinger]

Originally posted by James Carman:


Better yet, think of it as if you are coding in Java! All objects are passed by reference in Java! :-)

...which I understand. But I wasn't sure if an HttpSession object worked the same way since it's a server side thing.

[Jeanne Boyarsky]

Originally posted by Stan James:
Does anyone have team practices to avoid what Jeroen described? A list of variable names in use, naming conventions? Seems like a very easy and probably very common mistake.

Yes. We have an interface where we define all the names of things stored in the session. (Yeah I know, a constant interface...) The person who starts using a new variable enters it in the interface. If it is already there, the name is in use and would cause all sorts of conflicts.

For larger projects, we have an interface for each tab (part of the application.) The constants in each interface all start with a common prefix to avoid conficts between tabs.

[Jeffrey Spaulding]

So you say putting back those values all these years was in vain ?

I am so depressed.