> From: Nenad Kovacevic [mailto:micami...@yahoo.com] > Subject: Getting the Right High Availability Architecture for Tomcat > > If the session is replicated across the cluster should it not be > irrelevant where a request gets processed?
The problem is that multiple requests associated with a single session may be occurring simultaneously. Unless you have sticky sessions, you would have to replicate each session modification as it occurs, using appropriate cross-node locking. (This is usually considered to be a performance killer, as you might imagine.) Replication normally occurs only at the completion of a request, and, with sticky sessions, normal Java locking techniques can be used to insure that concurrent request processing maintains session integrity. You could implement some form of session ownership so that only one node has the updatable copy at any given time, and only give up ownership when needed. Still complicated, and still has performance issues. > Is Tomcat smart enough not to generate an ID that was already > created by another instance in the cluster or one has to ensure > uniqueness through configuration using jvmRoute attribute The latter is required at the moment. It would be fairly trivial to modify the session ID generation logic to limit each node to a specific range of values (it's only an integer); this would eliminate the need to set jvmRoute. Have you considered doing the SSL processing in the load balancer(s)? It would make life simpler. - 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
