Chapter 17: Clustering persisted session at fail-over time
Chapter 17: Clustering persisted session at fail-over time can be immediately handled by any one of the remaining servers in the cluster. Note that sticky sessions must still be configured in the mod_jkwith this scheme. This means that most of the time, a session will be serviced throughout its lifetime by the same Tomcat instance. The only exception occurs when the original server crashed during the session s lifetime. Sticky sessions also increase the probability that the session will be persisted to the store. This is because the longer the session lingers around, the greater the probability of it being persisted. The advantages of this session-sharing scheme include the following: . Application scalability through round-robin load balancing (new sessions are always created on the next worker in the round-robin queue). . Relatively easy setup and maintenance. The mod_jk lb(load balance) worker will detect crashed servers and reinstate recovered ones. . It provides a measure of HA in most situations because any persisted session is shared and can be handled by another server in the cluster. The disadvantages of this session-sharing scheme include the following: . Some sessions may still be lost during fail-over. . Access traffic on the network supporting the shared file system can be heavy in a highly loaded server cluster. Sticky Sessions with a Persistent Session Manager and a JDBC -Based Store Note in Figure 17-6 that there is no conceptual difference between this session-sharing scheme and the previous one. In fact, they both use the same Persistent Session Manager component. In this case, JDBC is used to persist session information onto an RDBMS. The set of benefits and weaknesses remains identical to the previous scheme. The only additional benefit of going to a JDBC-based scheme is the potential performance improvement on systems persisting a large number of sessions. If the applications running on the cluster are using the same RDBMS as the Persistent Session Manager, however, this slight performance edge may disappear (because of increased contention). In-Memory Session Replication Unlike the other two session-sharing schemes, this session-sharing mechanism is not built on top of a shared persistent storage. With in-memory session replication, session information is maintained in synchronization within the memory, across the clustered server instances. Two replication patterns are supported by Tomcat 6. In the first replication pattern, all sessions are replicated between all server instances. In the second pattern, sessions are replicated between only a server and its backup instance, regardless of how many servers are on the connected network cluster. Because two or more instances share the same session information, these session replication mechanisms have the potential to provide the full benefits associated with clustering. Figure 17-7 illustrates how this is accomplished.
If you looking for unlimited one inclusive web hosting plan please check web hosting plan website.