Thank you all for your help. I think we have it resolved and it was indeed the WLCookieName parameter (JSESSIONID) in the weblogic plugin that was set incorrectly. This has led to heavy discussion however with regards to this question: Is it really a good idea to implement the SessionAware interface and use a separate Hashmap to hold the user's session data? Would it not be perhaps safer and more efficient (and reduce the possibility of clustered session replication issues) to simply get the session yourself and set the attributes directly into it? What benefit is there to making struts the middleman and using a separate Hashmap? We are having this debate currently at my co. and I am lacking a convincing reason to avoid dealing directly with the session. THanks!
You can configure sticky sessions, which means that requests that go to one server in your cluster will always go to that server. To me this defeats the purpose of the cluster because if that machine goes down the user will be sent to another server, but their session will be gone with the down server. However this is the best performing configuration. Another option is shared sessions and this is covered in the WebLogic documentation at http://edocs.bea.com. How or if the session is shared in a cluster has nothing to do with Struts or any web application really. Regards, Randy Burgess Sr. Web Applications Developer Nuvox Communications -- View this message in context: http://www.nabble.com/Does-Struts-2-support-clustering--tp16609897p16627886.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
