Hello Dennis, One, you have to make sure that the objects stored in the HttpSession object are serializable. This is to ensure proper session migration in the event of a server failure in the web/presentation tier. Two, you use either a software or a hardware load balancer for load-balancing which can offer a set of schemes for load distribution, e.g., round-robin. Hope this helps. Bharat
Joined: Jan 23, 2004
I am wondering what are the architecture impacts of session replication in a clustering environment. Is there any severely performance penalty? Basically my question is, which approach is better: 1) Don't support session failover. Considering the business nature of a ticketing system, failover and recovery may not be necessary. therefore no need to synchronize the session states among clusters. 2) Replicate session states in memory or in hardware.
Joined: Jul 30, 2003
Hello Denis, The session clustering does have an overhead, I have first hand experience in it. We had a production system where we were working with a three tier system with session state being maintained in HttpSession in the presentation tier as well as Stateful Session Beans in the Business tier. We found that it carried an overall overhead of about 25% when using a clustered environment in terms of speed of execution. The thoughput and capacilty increased though. To answer your question: I am not sure if you want to show the details of the clustered environment in the component diagram, it will needlessly complicate it. However, in your design notes/assumptions document, you may want to briefly address the load-balancing and fail-over, i.e., clustering benifits. That is what I am leaning towards for my solution. Hope this helps. Regards. Bharat