RE: Struts and state information
Web server can use three mechanisms to store the sessionid. 1. The SSL session id 2. The session id stored in a cooke 3. URL rewriting like you describe If you configure your web server to have persistent sessions it should be able to share the session in a load balancing scenario. If you use cookies to store all your state information you could ignore HttpSessions all together. There may also be an elegant way to use a filter to save and restore session state from the cookie. The performance hit of persistent sessions is something to keep in mind. Corneil du Plessis Technical Specialist Internet Development Retail Channels Standard Bank Direct +27 (11) 636-2210 Mobile +27 (83) 442-9221 ICQ# 66747137 -Original Message- From: Brett Elliott [mailto:[EMAIL PROTECTED]] Sent: 14 October, 2002 07:07 To: [EMAIL PROTECTED] 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? 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of Standard Bank Group Limited is proprietary to the company. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of Standard Bank. The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. __ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts and state information
Cookies is default for jsp containers, jsp only goes to session ids if it cant get a hold of the cookies. X is automatically generated by the container if a session is requested, either directly by calling request.getSession() or by configuring the specific jsp page for sessions. I think html:link and forms automatically pass session ids and there isnt anything you can do about it. Anyoen care to correct me? chanoch - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Although we routinely screen for viruses, recipients should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. -Original Message- From: Brett Elliott [mailto:[EMAIL PROTECTED]] Sent: 14 October 2002 06:07 To: [EMAIL PROTECTED] 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? 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts and state information
On Sun, 13 Oct 2002, Brett Elliott wrote: Date: Sun, 13 Oct 2002 22:07:13 -0700 From: Brett Elliott [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
