Obviously nobody has limitless memory and performance, that's why I'm
wondering if there is a rule of thumb for figuring out if it's going to
be too much for the server to handle. Is 100 users on a decent sized
app going to kill the server if it's all in the session? Is 200?
>>I think also jsf supports both approaches via
the ability
to store backing info on the client side via config option.
You mean using the x:saveState tag? I ran into some trouble with that
since you wind up with a copy of the object, then you have to jump
through some hoops with Hibernate since it's a copy, and you might not
have the same hibernate session the next time when you try to save it,
etc.
Or do you mean the stuff in the web.xml? I didn't think that config
had to do with how backing bean state was stored, just the jsf tree
information, but I could be wrong.
Thanks,
Jesse
Boyce, Keith Garry wrote:
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.
|
|
