Let me see if I understand this correctly, in the case of non-sticky sessions. Request 1 goes to node 1. Am I correct in saying that as long as Request 2 reaches node 2 before the session from node 1 has fully replicated over, the the inconsistent session problem exists?
Am I also correct in thinking that depending on the order of replication completion (whether the session from node 1 replicates over to node 2 first or vice-versa), the session that persists would be either the session from node 1 or from node 2, but absolutely not both? Since it seems that sticky sessions are the way to go to ensure greater application consistency, this leads to the question that with all the benefits of sticky sessions, using what criteria would anyone decide against using them? What's the tradeoff here? Thanks. Caldarale, Charles R wrote: > >> From: lightbulb432 [mailto:veerukrish...@hotmail.com] >> Subject: Cluster session sync question (from documentation) >> >> How, for example, would a client be able to access the same session >> simultaneously? > > If a page includes multiple resources (e.g., frames, pictures), a browser > will normally generate at least two requests in parallel for those > resources. If those parallel requests are for dynamic content, it's up to > the servlets involved to synchronize updates to the common session object. > That's relatively easy in a non-clustered environment, but much trickier > with clustering - unless using sticky sessions in your load balancer. > > With sticky sessions configured in your load balancer, the concurrent > request problem devolves to the same one you already have in a > non-clustered environment. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail > and its attachments from all computers. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -- View this message in context: http://www.nabble.com/Cluster-session-sync-question-%28from-documentation%29-tp23411578p23413085.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
