session vs request

[Jesse Vitrone <je...@agentscape.com>]

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

Re: session vs request

[Jesse Vitrone <je...@agentscape.com>]

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 <je...@agentscape.com> 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/users@myfaces.apache.org/msg01696.html
>>
>>HTH,
>>sean
>>
>>
>>On 7/7/05, Jesse Vitrone <je...@agentscape.com> 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
>>
>> 
>> 
>>
>> 
>> 
>>
>>    
>>
>
>
>
>  
>

Re: session vs request

[Sean Schofield <se...@gmail.com>]

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 <je...@agentscape.com> 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/users@myfaces.apache.org/msg01696.html
> 
> HTH,
> sean
> 
> 
> On 7/7/05, Jesse Vitrone <je...@agentscape.com> 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
> 
>  
>  
> 
>  
>  
>

Re: session vs request

[Jesse Vitrone <je...@agentscape.com>]

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/users@myfaces.apache.org/msg01696.html
>
>HTH,
>sean
>
>
>On 7/7/05, Jesse Vitrone <je...@agentscape.com> 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
>>
>>    
>>
>
>
>
>  
>

Re: session vs request

[Sean Schofield <se...@gmail.com>]

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/users@myfaces.apache.org/msg01696.html

HTH,
sean


On 7/7/05, Jesse Vitrone <je...@agentscape.com> 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
>

Re: session vs request

[Werner Punz <we...@gmx.at>]

Craig McClanahan wrote:

 >On 7/8/05, Werner Punz <we...@gmx.at> wrote:
 >
 >>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.
 >>
 >
 >UIltimately, a standardized solution to this problem really belongs in
 >the servlet spec so that the entire web tier can use it.  In the mean
 >time, Shale's approach works like this:
 >
I agree we need a scope scope in the servlet tier, the gap is in the 
servlet tier and has been carried along for years without really a 
decent low level fix.


 >* You have a "Status" bean that the framework uses to
 >  keep track of navigating through a particular dialog.
 >  Among other things, it knows how to do nested dialogs.
 >
 >* This bean has a "data" property of type Object, so the
 >  application can push any sort of bean it wants, to save
 >  and restore state for that particular dialog.
 >
 >* As a new dialog is entered, the current data object is
 >  pushed onto a stack so that the new dialog can push
 >  on its own data object.
 >
 >* When a dialog is exited, the stack is popped, making
 >  the data object from the previous dialog is made visible
 >  again, and the state for the just-completed dialog is
 >  released for garbage collection.
 >
 >>From a JSF perspective, this approach has the additional advantage
 >that a value binding expression to access the state information stays
 >the same ("#{status.data.foo}") no matter how deep the stack of nested
 >dialogs is -- the data for the currently executing dialog is always
 >the state that is visible to the expression.
 >
 >Craig
 >
Thanks for the explanation Craig, basically what I was thinking of but 
more on a backend level, because you do the dialogs on a config file level.

I am thinking currently and have been thinking about that, more along 
the lines of having dialog/scope tags which basically mark an entire 
scope which can be accessed, but never had time to implement it.

The base mechanism of my idea works pretty much the same, but the entire 
scoping is done on the UI tier, with simple tags which the designer can 
set...
Anyway some kind of dialog/scope system has to be added to the official 
specs, the lower the better :-)

Re: session vs request

[Craig McClanahan <cr...@gmail.com>]

On 7/8/05, Werner Punz <we...@gmx.at> wrote:
> 
> 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.
> 

UIltimately, a standardized solution to this problem really belongs in
the servlet spec so that the entire web tier can use it.  In the mean
time, Shale's approach works like this:

* You have a "Status" bean that the framework uses to
  keep track of navigating through a particular dialog.
  Among other things, it knows how to do nested dialogs.

* This bean has a "data" property of type Object, so the
  application can push any sort of bean it wants, to save
  and restore state for that particular dialog.

* As a new dialog is entered, the current data object is
  pushed onto a stack so that the new dialog can push
  on its own data object.

* When a dialog is exited, the stack is popped, making
  the data object from the previous dialog is made visible
  again, and the state for the just-completed dialog is
  released for garbage collection.

>From a JSF perspective, this approach has the additional advantage
that a value binding expression to access the state information stays
the same ("#{status.data.foo}") no matter how deep the stack of nested
dialogs is -- the data for the currently executing dialog is always
the state that is visible to the expression.

Craig

Re: session vs request

[Werner Punz <we...@gmx.at>]

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