Digby has the right idea... It's not a question of which is "better",
it's a question of which is "appropriate" for what you are doing.
Many people do not deal in clustered environments, nor do they deal
frankly with high scalability requirements. I have to deal with both of
those concerns in my daily work. One of the things you learn in a hurry
is that storing anything in session that doesn't really need to be there
has a negative impact on both. Even in a single-server environment,
scalabilty can be adversely affected fairly quickly when session size
isn't a concern to a developer.
My rule of thumb is to put everything in request unless I know for sure
there is a reason to put it in sesion. This might be a need across
multiple pages as Digby says, or just because I know it is somewhat
expensive to reproduce the content (i.e., maybe a complex SQL query).
And when I do have to put anything in session, I try and store the
smallest amount of data I possibly can to accomplish what I'm doing.
I have never had a situation where I needed application context by the
way, not for something that deals with request servicing. I don't know
if it is true these days to be honest, but back when I did nothing but
Microsoft-based development, it was a pretty well-known fact that it was
more expensive to store things in session than in request, and even more
expensive to store things in context than session. Even if that isn't
true today in the Java world, I still proceed as if it is because that
mentailty tends to push stored data/objects down to where they should be
in terms of lifetime and scope.
Frank
Digby wrote:
IMHO, I would suggest storing objects for the shortest time possible. If
an object is only going to be used once, there's no point clogging up
memory with lots of unused objects, which won't be garbage collected
until the session is destroyed.
My rule of thumb is to use the request when it's a one-off, the session
if it might be used by another page, and the application if it will be
used by more than one user (which is quite rare).
Digby
Adrian Beech wrote:
Hi all,
A work colleague mentioned on Friday it would be better to place objects
(beans and the like) which had been created in a servlet into the request
context when exposing them to the JSP. To date all the code I've written
stores beans and the like in the session context and all has appeared
to be
fine thus far. I understand the nature of the various contexts and
how they
relate to the process life cycle, etc.
Can someone please shed some light on this and possibly explain the
merits
of placing the objects in either context? For example, what are the
pitfalls of using the request context? Is there any material around
which
adequately details when or when not to use the specific contexts?
Cheers.
AB
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
