|
If you have limitless memory and limitless performance then
you won't have to worry about memory size and performance of course... So
calculate how many users you expect to have sessions at one time and the
performance and memory implication for these users and plan accordingly.
Otherwise take the approach of the worst case scenario in that you don't know
the answer to these questions. In that case limit the session use as much as
possible (that could mean not using session at all). These are the obvious
answers to your question I think.
I think also jsf supports both approaches via the ability
to store backing info on the client side via config option.
Garry
That thread has a noticable lack of talk about performance issues
or worrying about memory size. That was my main concern, does that mean
that it's not something that I really have to worry about?
Interesting
points about outside changes to data and winding up with dirty data, something
to think about. Thanks for the info.
Jesse
Sean Schofield
wrote:
True. I only knew to keep looking because I distinctly remembered
such a conversation with Craig way back when.
sean
On 7/7/05, Jesse Vitrone <[EMAIL PROTECTED]> wrote:
Sean,
Thanks for the link, I searched the archive before posting, but
searching session and request comes up with so much, I didn't find what I
was looking for.
Thanks,
Jesse
Sean Schofield wrote:
There have been a few interesting discussions about this on the list
before. Here is a link to one thread of interest:
http://www.mail-archive.com/[email protected]/msg01696.html
HTH,
sean
On 7/7/05, Jesse Vitrone <[EMAIL PROTECTED]> wrote:
I have always learned, don't put stuff in the session unless you have
to, so when I started my project, I made all of my backing beans request
scoped, but started wondering lately if there are benefits to keeping
them in the session.
Is there a valid argument for making them session beans? You could
argue that you're using less database resources by not having to hit the
database over and over for the same information that you've already
gotten. Less network traffic because you're not passing as many request
params around all the time. Less code in your jsp's because you don't
have to write out hidden fields all over the place.
Are these points enough to offset the server overhead of keeping this
info all the time in the session? I guess it depends on how many
concurrent users you have to worry about. Is there a rule of thumb for
how many users you have before you start to kill your server with too
much in the session? The project this is for is a pay site that you
have to log in for, so it's not going to have the thousands of public
users surfing the site at one time, it's more like a thousand users
total and *maybe* a few hundred logged in at a time. Is that enough to
worry about session sizes?
Any other arguments for or against sessions over requests? Am I crazy
for even considering making most of my beans session scoped?
Jesse
This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy,
or use it, and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message, and then
delete it from your system. Thank you.
|
|
