There has been an interesting shift lately with people more apt to put
things in session. I think a lot of it stems from what newer frameworks
are doing and people taking some cues from them. There are certainly
some obvious advantages, and the old disadvantages aren't nearly as big
a deal as they used to be.
The one thing I always like to point out however is that you cnn really
make a bad choice if you don't work in a clustered environment. Many
people still work in single-server environments. In such a situation,
putting more in session almost entirely comes down to just dumping more
memory in the server. Very little else matters a whole lot.
In a clustered environment though, you want to be a whole lot more
careful. More importantly, even if you are in a single-server situation
now, carefully consider what happens if you move to a multi-server
environment (I know, this happened to me!). Session replication across
nodes can come back to haunt you big-time.
Of course, it's always a matter of trade-offs... is that session
replication going to be better or worse than continually hitting a
database to regenerate a dataset if you are doing things per-request?
There's no general-purpose right or wrong answers.
The one pointer I give people about this is to carefully consider what
you are thinking of putting in session, and ultimately put as little as
possible, but put enough to have a tangible benefit. If your doing a
wizard-like interface as Wendy describes, you can either store the built
up data in session, or you can pass it around between requests, or you
can put it in a database or other persistent store temporarily. The
session option winds up being the best in most cases, in terms of
performance, simplicity and server load.
Frank
Murray Collingwood wrote:
Two responses and both suggesting I push all my beans into the session scope.
This really does beg the question, what purpose is the request scope for a bean? My
only answer was display-only material. Is this really how it was designed?
Sorry to be asking so many design questions but I really find it hard to understand that
after all of these years (of Object Oriented Design) we are still using globals to store
values that are processed through one form.
Kind regards
mc
On 11 Sep 2005 at 21:13, Wendy Smoak wrote:
From: "Murray Collingwood" <[EMAIL PROTECTED]>
I guess pushing the form bean into the session would do this, but session
variables for a
request level function is probably not recommended.
It is by me. :) Put the form in session scope, and most of your problems
will disappear. You pick up a couple of new ones, but the tradeoffs are
generally worth it.
One of my webapps deals exclusively with editing records, and it takes
several requests to finally complete an edit (or an add). All that time, I
have a DTO (Value Object... what are we calling them this week?) and a form
bean in session scope, updating the DTO as necessary until the user hits
'Finish'.
The database key is read-only, in fact it's never in the form bean, it gets
displayed with <c:out> directly from the DTO.
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 10/09/2005
FOCUS Computing
Mob: 0415 24 26 24
[EMAIL PROTECTED]
http://www.focus-computing.com.au
--
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]
