Struts and state information

[Brett Elliott <br...@att.net>]

I would like to keep session state soley in cookies so I can use round robin
HTTP load balancing versus sticky load balancing(sticky load balancing as in
all requests are directed at a specific web server for a given user.

I read Professional JSP, perused this mailing list and looked on the web and
nothing really elaborates on where the state is stored by default.  I see
how the <html:link> </html:link> directive is translated into <a
href=http://...;jsessionid=X></a> but where does it get X and where does it
store the session information related to X?  Does it rely on the jsession ID
being passed around in URLs then keep the associated session information
cached on the server?  So if you have multiple servers you will need to use
sticky load balancing to make sure users only use one webserver?

What options are there in case I want to keep all session state in cookies?
That is, ideally, I would generate an encrypted cookie w/ CRC containing the
logged in username and minimal information about the user.  And I would like
to do this within the confines of Struts.

Thanks for any help and I aplogize if this is a redundant question.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Struts and state information

["Craig R. McClanahan" <cr...@apache.org>]

On Sun, 13 Oct 2002, Brett Elliott wrote:

> Date: Sun, 13 Oct 2002 22:07:13 -0700
> From: Brett Elliott <br...@att.net>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: Struts and state information
>
> I would like to keep session state soley in cookies so I can use round robin
> HTTP load balancing versus sticky load balancing(sticky load balancing as in
> all requests are directed at a specific web server for a given user.
>
> I read Professional JSP, perused this mailing list and looked on the web and
> nothing really elaborates on where the state is stored by default.  I see
> how the <html:link> </html:link> directive is translated into <a
> href=http://...;jsessionid=X></a> but where does it get X and where does it
> store the session information related to X?  Does it rely on the jsession ID
> being passed around in URLs then keep the associated session information
> cached on the server?  So if you have multiple servers you will need to use
> sticky load balancing to make sure users only use one webserver?
>

The "X" is the session identifier created by the container.  Containser
that support multiple back-end servers are *required* to ensure that, at
any given point in time, all requests for the same session id must go to
the same server.  Advanced containers may support session migration or
failover, but they are only allowed to move the session in between
requests.

Using a simple-minded round robin load balancing scheme violates this
principle, and will cause you nothing but grief -- consider what happens
when two simultaneous requests for the same session are sent to two
different server instances, and they both update state information in
their own copy of the session attributes.

Your application's responsibility is to ensure that all the session
attributes you create are Serializable - then it's up to the container to
manage all of this for you, basically transparently.

> What options are there in case I want to keep all session state in cookies?
> That is, ideally, I would generate an encrypted cookie w/ CRC containing the
> logged in username and minimal information about the user.  And I would like
> to do this within the confines of Struts.
>
> Thanks for any help and I aplogize if this is a redundant question.
>

"Session state is kept wherever you store it".  :-)

More seriously, cookies *sort of* correspond to session attributes, which
is where you store state on the server side if you want to keep it.
However, cookies have a couple os significant restrictions:
* They can store only Strings, not objects
* There is a limited capacity for storing cookies

So, like everything in life, this is a decision of tradeoffs.

Another alternative you should also consider, though, is storing your
state information in hidden fields in the forms you create, so that it can
be reread on the following submit.  Although such attributes are still
Strings, you don't have the length limits of cookies -- and it's easier to
debug because you can "View Source" the pages to see what's really there.

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>