velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Bubna" <>
Subject Re: This question has "first major web app" written all over it.
Date Fri, 11 Apr 2003 20:37:40 GMT
John said:

well, these aren't really velocity issues at all, but...

> I have spent so much time trying to figure out the best way to pass
> around member related information.   For some reason I seem to lose my
> session and I am having a hard time understanding why.
> I follow this chain:
>     --> Welcome.vm --> Logon.vm -->
>                     --> --> Welcome.vm
>                     --> EditMember.vm -->
> I appear to have the Member record stored in session after the logon
> and all the way through to the EditMember.vm as information appears
> there (unless I refresh at which point it all disappears -- why I
> don't know).   When I head to the, the session information
> is totally clear.

hmm.  assuming that you really putting your Member record in a valid session
and you are not invalidating that session along the way, this doesn't make a
lot of sense to me.  question:  does the browser you are using support
cookies and/or have cookies turned on?  if the answer to either of those is
no, then you should keep an eye on the urls and be sure that the jsessionid
is being kept in them as you go.  AFAIK, these are the ways servlet engines
(Tomcat, in this case) identify which HttpSession object (if any) is
associated with particular browser requests.

> This inability to get session working made me hunt for the last couple
> days for an answer.   In great part I spent the time learning.
> In my lookings, I came to this:

uh.  didn't read it carefully, but IMHO, they're being a little overly
paranoid. also, their "pros and cons" include things that don't apply to
Java developers.  their basic concern is memory performance.  as always,
balance is required.  if you never use any session data, then you must
either face the maintenance headache of passing lots of data around in your
URI query string and/or the processor performance hit of pulling relevant
user-related data from a database on every single request (unless you have
good working database caching).  either way, you have potential for
performance and/or maintenance headaches.  balance, moderation, and common
sense are better guidelines.  by using ASP, those fellas may have already
forfeited common sense ;-).

> This made me concerned that perhaps I am going about my work the wrong
> way today.   Maybe Sessions are not the right means as they may not
> allow for scalability.  Concern is of course for need of great amounts
> of garbage collection and also need to serialize records.

uh, won't garbage collection be a greater concern if you are pulling your
data from the URL or database every time?  that would mean creating and
discarding objects for the same data on every request instead of once per
session.  as for serializing, yes, it is recommended, encouraged, and
technically proper to have all objects stored in the HttpSession be
serializable, but AFAIK, this is only so that existing sessions can be
maintained across shutdown/restarts of the webapp and/or servlet engine
itself.  apart from that, your session data should not end up being
serialized.  further, if your session attributes are not properly
serializable, it will not be the end of the world.  it just means that any
actively logged-in users will lose their sessions any time you have to
restart the app.

> The artical
> seems to feel that URL rewriting is the only way (which means perhaps
> also the only way is need for backend database caching mechanism).

good database caching is handy, and can certainly alleviate your concerns,
but i don't think your concerns are that big of a deal.  that is not the
"only way."

> In my first run at my site, I was placing a large ArrayList of job
> listings into the session as I could not think of a better way to get
> job listings in there in a pluggable kinda way.   Some of the job
> listings would be common to all users and some would be specific
> queries to individual users.  Thinking about doing this for every user
> sounds like a massive serialization and memory risk.

serialization risk?  uh, see above comments.

look, here's a decent set of guidelines for you:
-if the data is something pertinent to the current request and is not likely
to be used on many subsequent requests, then you should almost certainly put
the data into the request attributes.  this can be done by a struts Action
class or you may create a request-scoped tool that retrieves the data and
makes it available to the template.

-if the data is something closely connected to the user (like a user name,
id, view preference, whatever) then you might consider putting it in some
sort of MyUser object and putting that object into the session attributes.
putting each piece of data in the attributes separately is poor OO-style.
the alternative is keeping the user id in *every* URL and pulling the tied
data or user object from the database whenever needed.  in our apps, we
usually put the user object (part of our model) in the session (usually
under non-velocity friendly key like 'user.key') and let a session-scoped
UserTool actually do the retrieving of the object and expose the
data/methods we need to the template.

-if the data is something that all users will be making common use of, then
you might consider putting the data in the application attributes (if not
just making it statically accessible somewhere in your code).  i would then
use an application-scoped tool to retrieve and/or expose this data.

Nathan Bubna

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message