Jesse Vitrone 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.
Yes many... you dont have to traverse data over the pages for
instance... A scope bigger than a session basically gives you
a state system to a stateless ui HTML basically is.
But one of the biggest gaps of the current JSF specs is that you do not
have local scopes... scopes which are bigger than a request but smaller
than a session. Shale has something with the dialog system, which I have
not checked out yet.
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.
The only argument against session beans is, that they suck up ram if you
have more than a handful of users, so most people shy away from them for
this obvious big disadvantage. Besides that there are no real
disadvantages to them.
As I said some kind of local scope would be better.
There is also the x:saveState in myfaces which can do this job without
touching the session.
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?
Depends also on your machine infrastructure, but I would recommend to
look into x:saveState and the shale dialog system, that might solve your
problem better than pushing the session extensively. The main problem is
that you often have to keep the sessions for longer periods of time,
even if the user does not have an open browser anymore, the session is
still in ram for some time until it times out. Thus even if you have
only a few hundred page requests per hour all of these hundred might be
at the same time in ram although some users visited the site only for a
few seconds.
Any other arguments for or against sessions over requests? Am I crazy
for even considering making most of my beans session scoped?
Jesse
Not it is a logical choice, which I considered often also, as I said,
shale might be the perfect solution. What I could think of as well,
would be some kind of scope control, which opens a local subsession on
your session and you can push into this scope everything you like, and
it is kept as long as the scope control is in the page.
Sort of like an x:saveState for the session, without the culprit of
having to make the affected objects serializable.
Werner
