Chapter 17: Clustering In Figure 17-5 , incoming
Chapter 17: Clustering In Figure 17-5 , incoming request A is routed to tomcat1 because session X is created and maintained on the tomcat1 instance. Meanwhile, request B is routed to tomcat3 because session Y is created and maintained on the tomcat3 instance. Request C has no session, so it is routed to the next server in the round- robin distribution, which is tomcat2. This is a highly functional clustering configuration that is relatively easy to configure, and it can be used to scale a Web application across a cluster of Tomcat 6 servers. The only disadvantage of this configuration is that sessions are Tomcat instance specific. If a Tomcat instance is lost, all its sessions are lost. For example, in Figure 17-5 , if the tomcat1 instance crashes, session X is lost forever. Request A will not be handled by the system, and the user will lose the session (and whatever was being done at the time the failure occurred). However, if there is some way to help the clustered Tomcat instances to share session information, then one of the other Tomcat instances still up and running can take over and service incoming requests with sessions created by the crashed server. Session Sharing As with the load-balancing frontend, you have numerous session-sharing backends from which to choose. Each provides a different level of functionality, as well as implementation complexity. Session sharing is the secret behind most implementations of an application server fail-over mechanism. It ensures transparent transfer of the sessions that were being handled by the crashed server. In the following discussion, we assume that the mod_proxyor mod_jk load balancing frontend is used. These are the most popular production configurations for clustered Tomcat 6 instances. The available session-sharing configuration options include the following: . Sticky sessions with no session sharing . Sticky sessions with a Persistent Session Manager and a shared file store . Sticky sessions with a Persistent Session Manager and a JDBC store to RDBMS . In-memory session replication Sticky Sessions with No Clustered Session Sharing This is the scenario that was tested in Chapter 11 , when mod_jk and an AJP Connector were used to round-robin requests amongst a cluster of Tomcat 6 server instances. In this scenario, the mod_jk lb (load balance) worker ensures that requests destined for the same session are always handled by the same Tomcat worker instance. The session ID is encoded with the route name of the server instance that created it, assisting in the routing of the request. While this setup may sound contrived, it is extremely practical and pragmatic in many production scenarios. The advantages of this simple clustering setup include the following: . Application scalability through round-robin load balancing (new sessions are always created on the next worker in the round-robin queue) . Simplicity in setup and maintenance (the mod_jk lbworker will detect crashed servers and reinstate recovered ones) . No additional configuration or resource overhead (as no session sharing is occurring)
For reliable and cheap web hosting services please check javaweb hosting website.