Preface:
There are two main ways to manage session in a Tomcat cluster:
1). Sticky session
Indicates that requests sent from the same window will be processed by the same tomcat in the cluster. The configuration is workers.properties the XML code worker.lbcontroller.sticky_session = True in the file above
The advantage of sticky sessions is that it does not bounce back and forth on different tomcat, but the downside is that if the tomcat that handles the session crashes, the subsequent request will be renewed by another tomcat, and the original session fails to create a new session. This throws a Nullpointer access exception if you continue to take a value from the session.
2). Session Replication
Session replication refers to the way that Tomcat sends sessions to each Tomcat instance through multicast.
The advantage is that if one of the accesses fails, Tomcat still has a valid session content, allowing it to take over its session normally.
The downside is that when there are a lot of tomcat instances, or when the user has a lot of action in the session, the amount of information sent by the group is staggering. The session replication configuration adds XML code < distributable to the Web.xml in the published Web application/>
In addition, the JDK required for session replication must be JDK 5.0 and above.
==============================================================
First part
Original address: Http://www.on java.com/pub/a/onjava/2004/11/24/replication1.html
The TOMCAT 5 server provides integrated support for cluster and session replication. The first article in this series will provide an overview of session persistence and the intrinsic working mechanism of session replication in the Tomcat cluster. I will discuss how session replication works in TOMCAT5 and the replication mechanism that spans the session persistence of multiple cluster nodes. In the 2nd installment, I will discuss in detail an example of a Tomcat cluster with session replication, and compare different replication scenarios.
Cluster
Traditional stand-alone servers (not clustered) do not provide any failover and load-balancing capabilities. When the server fails, the contents of the entire Web site cannot be retrieved unless the server is recalled. Any session stored in server memory will be lost because of server failure, and users must log back in and enter all data that is lost due to server failure.
The difference is that servers that are part of a cluster provide testability and fail-through seamless transfer capabilities. A cluster is a set of multiple server routines that run synchronously and work together to provide high reliability, high stability, and high testability. Service-side clustering appears to be a separate server routine for clients. From the client's perspective, the cluster's clients are not much different from the individual servers, but they provide uninterrupted service and session data persistence by providing results seamless transfer and session replication.
server communication in a cluster
Application servers in a cluster share information through technologies such as IP multicast (IP multicast) and IP sockets and other servers
IP multicast: Mainly for 1 to many server communications, through broadcast services and heartbeats messages available to display the effective server
IP sockets: Mainly used for Peer-to-peer server communication in cluster server routines
one-to-many communication using IP multicast
The TOMCAT server uses IP multicast for one-to-many communication between server routines in the cluster, and IP multicast is a broadcast technology that enables multiple servers to subscribe to specified IP addresses and port numbers and listen for messages (multicast IP address ranges from 224.0.0.0 To 239.255.255.255). Each server in the cluster uses multicast to broadcast specific heartbeat messages, and by monitoring these heartbeat messages, the server routines in the cluster determine when the server routine is invalidated. One disadvantage of using IP multicast in server communications is that he cannot guarantee that the messages are actually received. For example, an application that continues to have a local multicast cache full will not be able to write a new multicast message, and the application will not be notified after the message has been sent.
using IP Sockets for server communication
IP sockets also uses a set of mechanisms for sending messages and data between servers in a cluster. The server routine uses IP sockets to replicate the HTTP session state between cluster nodes. The correct soket configuration is critical to the performance of the cluster, and the efficiency of the socket based communication depends on the implementation category of the socket (for example, the system uses a local or a pure Java Socket Reader), if the server uses a pure Java The socket reader depends on whether the server routine registers with enough socket reader threads.
If you want the best socket performance, the system should register to use local Socekt instead of a pure Java implementation. This is because the local socket consumes less system resources than the Java-based socket implementation. Although the Java implementation of the socket reader is a reliable and mobile method in Peer-to-peer communication, he cannot provide the best performance for heavy socket usage in a cluster. The local socket reader uses a more efficient method when determining whether there is data reading from the socket. Implemented using the local socket reader, the reader thread does not need to count the still sockets: they are only serving the active socket and can be captured immediately when a given socket starts to become active. With a pure Java socket reader, the thread must dynamically count all open sockets to determine whether they contain readable data.
In other words, the socket reader is always busy counting the sockets, even if the sockets have no data to read. These should not be the overhead of a system that lowers performance.
Cluster in TOMCAT 5
Although there are cluster features in earlier versions of TOMCAT5, in later versions (5). 0. 19 or higher), the cluster changes to a more modular component. The cluster elements have been refactored in the server.xml so that we can replace different parts of the cluster without affecting other elements. For example, the member service is set to multicast discovery in the current configuration. It is easy to replace member service modifications with TCP or Unicast, without altering other parts of the set class logic.
Other cluster elements, such as the session manager, the replication sender, can also be replaced by custom implementations without affecting other parts of the cluster configuration. Similarly, any server component in the Tomcat cluster can use the Set class API to send messages to all members of the cluster.
Session Replication
Server clusters typically manipulate two kinds of session:sticky sessions and replicated sessions. Sticky sessions is the existence of a stand-alone server to accept the network request session, the other cluster members of the server session state is completely unclear, if there is a session of the server failed, users must again login site, Re-enter all the data stored in the session.
The other type of session is that, on one server, the sessions state is replicated to all other servers in the cluster, and whenever a session is changed, it is replicated again. This is replicated session. Sticky and replicated sessions have their pros and cons, sticky sessions simple and easy to operate because we don't have to replicate any session data to other servers. This will reduce system consumption and improve performance. However, if the server fails, all session data stored in that server's memory will also disappear. If the session data is not replicated to another server, the session is completely lost. When we are doing a query transaction, losing all the data that has been entered can cause a lot of problems.
To support the automatic failure seamless transfer of the JSP HTTP session state, the Tomcat server replicates the session state in memory. This is done by replicating the session data stored on one server to other members of the cluster to prevent data loss and allow seamless transfer of failures.
state management of Objects
There are 4 different objects that can be distinguished by the state of saving on the server:
Stateless: A stateless object does not hold any state in memory when invoked, because the client and server side do not need to save any information about the other. In this case, the client sends the data to the server every time the server is requested. Session state is sent back and forth on the client and server side. This method is not always feasible and ideal, especially when the data transmitted is large or some security information we do not want to save on the client;
Session: A Session object is used only for a specific client in a sessions. In session, he can serve all requests from the client, and only the client's request. Throughout a session, the state information between two requests must be saved. Session services typically hold a transient state in memory and may be lost when the server fails. Session state is usually saved in the memory of the server between requests. In order to empty the memory, the session state can also be freed from memory (as in an object CACHE). In this object, performance and scalability need to be improved, since updates are not written to disk alone, and data cannot be salvaged when the server fails.
Caching: The cached object holds state in memory and uses this to handle requests from multiple clients. The implementation of the caching service can be extended to keep the cached data backups in the back-end storage (usually a relational database).
Independent: An independent object is active only on one server in the cluster at a time, processing requests from multiple clients. He is usually supported by those that are private, persistent, and slow in memory. He also maintains a transient state in memory and rebuilds or loses when the server fails. When a failure occurs, the standalone object must be reset on the same server or ported to another server.
(Source: "Using WebLogic Server Clusters")
design Considerations for Session replication
Networking Considerations
Isolating multicast addresses from clusters and other applications is critical. We do not want the cluster configuration or network layout to interfere with multicast server communications. Sharing cluster multicast addresses with other applications will force the cluster's server routines to handle messages that are not expected to consume system memory.
Shared multicast addresses may also overload IP multicast buffers, delaying server heartbeat message transmission. Such a delay could cause a server routine to be identified as dead simply because his heartbeat message was not received in time.
Programming Considerations
In addition to the network-related factors mentioned above, some design considerations related to our application of Java EE Web applications also affect session replication. Some programming considerations are listed below:
Session data must be serialized: In order to support in-memory replication of the HTTP session state, all servlet and JSP session data must be serialized, and each domain in the object must be serialized so that the object is reliably serialized.
To design an application as idempotent: A power means that a drill does not modify state information and returns the same result each time (in other words: doing the same thing multiple times and doing it once), typically, Web requests, especially HTML forms Are sent multiple times (when the user clicks on the Send button two times, overloading the page multiple times), resulting in multiple HTTP requests. Designing a servlet and other Web objects that are idempotent can tolerate multiple requests. Details can be referred to the design pattern "Synchronized Token" and "idempotent Receiver" on how to design the power of the application.
In the business Layer storage State: Session state should be stored in the EJB layer using stateful sessions beans, rather than httpsession stored on the web layer. Because enterprise applications support various types of clients (Web clients, Java applications, other EJBS), storing data in the Web layer can result in dual data storage at the client. As a result, stateful session beans are used in these cases to store session state. The stateless session bean is to be reconstructed for each call. These states may have to be recompiled from the data recovered in the database. These shortcomings have lost the use of stateless session beans to improve performance and scalability, severely reducing performance.
Serialization system consumption: Serialization session data will return some system consumption when it is replicated. The more it consumes as the size of the serialized object grows. It is best to keep the session capacity appropriately small. But if you have to create very large objects in the session, it's best to test your servlets performance to ensure that the performance is acceptable and that the session copy time is appropriate.
User session: It is important to determine the maximum number of concurrent user sessions that are controlled by each Tomcat server routine in the cluster. To control more concurrent sessions, we should add more memory to improve efficiency. The maximum number of concurrent clients, and the frequency of each client request, is also a factor in determining the performance impact of session replication on the server.
Session replication in Tomcat 5
Prior to version 5, the Tomcat server only supported sticky sessions (load balancing using the MOD_JK module). If we need session replication, we must rely on 3rd party software such as javagroups to implement it. The Tomcat 5 Server has session replication capabilities. Similar to cluster features, session replication can be achieved as long as you modify the Server.xml registration file.
Martin Fowler about three session state persistence patterns in his book, Enterprise Patterns, which include:
1. Client session state: Store session state on client
2. Server-side session Status: Holds the session state to a system in a serialized form.
3. Database Session state: Stores session data when submitting data in a database.
Tomcat supports the following three types of session persistence:
1. Memory replication: The session state is replicated in JVM memory, using the Simpletcpcluster and Simpletcpclustermanager classes of the Tomcat 5 installation band. These classes are part of the Server/lib/catalina-cluster.jar in the package org.apache.catalina.cluster.
2. Database persistence: In this type, the session state is saved in a relational database, and the server uses the Jdbcmanager class to get session information from the database. This class is part of the Catalina.jar in the package Org.apache.catalina.session.JDBCStore.
3. File-based Persistence: This uses class PersistenceManager to save session state to a file system. This class is part of the Catalina.jar in the package Org.apache.catalina.session.FileStore.
Tomcat cluster elements and session replication
This chapter briefly describes the elements that make up the Tomcat cluster and session replication.
Cluster：
This is the main element in the cluster, and the Simpletcpcluster class represents this element. He uses the management class specified in Server.xml to generate Clustermanager for all available web contexts.
Cluster Manager
This class focuses on session data replication across all nodes in the cluster. All Web applications that have the distributable tag specified in the Web.xml file will have session replication. The cluster Manager is specified in Server.xml as the Managerclassname attribute of the cluster element. The cluster Manager's code is designed to separate elements from the cluster. All we have to do is write a session manager class to implement the Clustermanager interface. This gives us the flexibility to use the client Cluster manager without affecting other elements in the cluster. Here are two replication algorithms. Simpletcpreplicationmanager copies all sessions at a time, while Deltamanager only copies session increments.
The simplest replication Manager replicates all sessions at each HTTP request. This is useful when the session is smaller, and we can only use the following code:
HashMap map = Session.getattribute ("map");
Map.put ("Data", "data");
Here, we do not need to specifically invoke Session.setattribute () or RemoveAttribute methods to replicate session changes. For each HTTP request, all properties in the session are replicated. You can use a property called Usedirtyflag to optimize the number of times the session is replicated. If this tag is set to true, we must call the SetAttribute () method to get the replicated session changes. If set to False, the session is replicated after each request.
Simpletcpreplicationmanager build Replicatedsession perform session copy work.
Providing an incremental manager is only for performance reasons. It replicates every time the request is made. He also calls the listener, so if we call Session.setattribute (), then the listener on the other server will be invoked. Deltamanager build Deltasession perform session replication.
Members
The members are created by sending broadcast messages at the same multicast IP and port by the Tomcat routine. The broadcast messages include the IP address of the server and the TCP listening port (the default IP address is 228.0.0.4).
If a routine in a given time frame does not receive a message (specified by the Mcastdroptime parameter in the cluster configuration), the member is considered dead. This element is represented by the Mcastservice class.
The property started by Mcastxxx is used for membership multicast ping. The following table lists the properties that are used for IP multicast server traffic.
Sending End
This element is represented by the Replicationtransmitter class. When multicast broadcast messages are received, members are added to the cluster. The Send routine uses host and port information to establish a TCP SOCKET before the next replication request. Use these sockets to send serialized data. There are 3 different ways to manipulate session replication in Tomcat 5: Asynchronous, synchronous, pool-copy mode. The following sections explain how these patterns work, and how they will be used under what circumstances.
Asynchronous: In this replication mode, each cluster node has a single thread acting as the session data transmitter. Here, the request thread sends the replication request to a queue, which is then returned to the client. If we have sticky sessions, we should use asynchronous replication before failure seamless transfer. Copying time here is not crucial, but the request time is. During asynchronous replication, the request is returned before the data is copied. This replication mode shortens the request time. This is useful when each request is divided into more open mode. (For example, there is a longer delay between Web requests). Also, if we don't care whether the session is finished copying this is also useful, when the session is very small, session replication time is also shorter.
Sync: In this mode, a single thread performs HTTP requests and data replication. The thread returns after all nodes in the cluster receive session data. Synchronization means that the replicated data is sent through a single socket. Because of the use of a single thread, synchronization mode can be a potential bottleneck for cluster performance. This replication mode guarantees that the session has been replicated before the request is returned.
Pool: TOMCAT5 provides a great improvement in the method of session replication using pool replication mode. The pool mode is basically an extended version of the synchronization mode. He is based on the principle of dividing services into multiple routines, and each routine handles different session data fragments. At the same time, the receiving server open multiple sockets to send session information. This method is faster than sending everything through a single socket. Therefore, a session is replicated synchronously using a socket pool. The request is not returned until all session data has been copied. To effectively use this mode, you want to increase the TCP thread. Because of the use of multiple sockets, the pool pattern enables a gradual increase in cluster performance and better testability. This pattern is also the safest configuration because it has a sufficient number of sockets to send all session data to other nodes within an ideal time. The use of single socket,session data may be lost or only partially transmitted through the cluster.
Receiving End
This cluster element is represented by the class Replicationlistener. Properties that start with tcpxxx in the cluster configuration are used for TCP session replication. The following table lists the properties for configuring server replication based on Socekt server traffic.
Copying Values
The replication value is used to determine which HTTP requests need to be replicated. Since we don't copy static content often (such as HTML and JavaScript, stylesheets, image files), we can use the copied value element to filter out static content. This value can be used to find out when the request has been completed and to initialize the copy.
Deployment Device
A deployer element can be used to deploy a cluster-wide application. Typically, deployment only deploys/Undeploy the work members within the cluster. Therefore, there is no wars replication at the time the corrupted node is started. When watchenabled= "true", the Configurator monitors a directory (Watchdir) for the war file. When a new war file is added, the war is deployed to the local routine, which is then deployed to other routines in the cluster. When a war file is removed from the Watchdir, the war is released from the local and cluster scope.
All elements in the Tomcat cluster structure and their hierarchical relationships are listed in Figure 1
Figure 1. Tomcat Cluster Hierarchy Chart. Click to look at the original artwork.
How does session replication work in Tomcat?
The following sections briefly explain how the cluster nodes share session information when the Tomcat server is started or closed, and the details can be referred to Tomcat 5 clustering.
TC-01: The first node in a cluster
TC-02:2nd node in a cluster
Server startup: TC-01 starts with a standard server startup queue. When a host object is created, there is a cluster object associated with it. When contexts is parsed and if distributable is already specified in Web.xml, Tomcat creates the session manager for the Web context (Simpletcpreplicationmanager Replace Standardmanager). The cluster will start a member service (a routine for a member) and a replication service.
When TC-02 starts, he also follows the same queue as the first member (TC-01) But there is a difference. The cluster is started and a member relationship (TC-01,TC-02) is created. TC-02 will request session status to TC-01. TC-01 should request that the TC-01 send status to TC-02 before TC-2 starts listening for HTTP requests. If TC-01 does not respond, TC-02 will enter the abort state after 60 seconds and publish a log entry. The Sessiong state is sent to all Web applications that have distributable specified in Web.xml.
Create session: When a TC-01 receives a request, a session (S1) is created, processing the request to enter the TC-01 is the same as without the session replication. When the request completes, the following event occurs: Replicationvalve will intercept the request before the response is returned to the user. Here, you will find that the session has been changed, using TCP to replicate session to TC-02.
Server Storage/Transportation loss/shutdown: When one server in the cluster fails, the maintenance is corrupted or the system is upgraded, the other nodes are notified that the first node has been detached from the cluster. TC-02 removes TC-01 from his membership column, and TC-02 does not receive notification of any changes to TC-01. Load balancing will move to TC-02, and all sessions are controlled by TC-02.
When TC-01 begins to recover, he again follows the boot queue described in the start phase of the server. Joins the cluster and communicates with the current state and TC-02 of all sessiong. Once the Sessiong state is received, it completes loading and then opens its HTTP/MOD_JK port. Therefore, you will not be able to send the request until you receive the session state from TC-2 TC-01.
Session termination: If one of the sessions in the first node is invalid or due to expiration, the invalid request will be intercepted and sessions will be placed in a queue with the other invalid. When the request completes, the server sends the Sessiong termination message to TC-02 instead of sending the changed SESSION,TC-02 also invalidates the session. We can see the Sessiong invalid message from the server console. Invalid sessions will not be replicated in the cluster until other requests for outgoing systems are in place and invalid queues are checked.
Concluding remarks
In this article, I talked about some design considerations for session replication in a clustered environment, and for writing Java EE applications that require sessiong replication in memory. I also discussed the cluster elements that were specified in the Tomcat 5 container for Sessiong replication. In the 2nd part of the series, we will look at how to configure Sessiong replication in the Tomcat cluster using different Sessiong manager and replication modes.
Srini Penchikala is an information system subject expert working in the Flagstar bank.
Part II
cluster Installation
In order for session replication to be available in the TOMCAT5 container, the following steps must be completed:
For a cluster to work, you have to use multicast on your system to use
For some use of session replication, all Tomcat routines must be configured equally. This means that the Web application must be deployed uniformly on each server in the cluster. These configurations also simplify cluster management, maintenance, and discovery of maintenance failure tasks.
Server.xml Cluster and valve (REPLICATIONVALVE) elements that are not annotated. The use of the cluster element in SERVER.XM means that the session manager for all Web context will change. So when running a cluster, you should make sure that only one needs to be integrated into the Web application and remove the other.
If the server routine runs on the same machine, you should ensure that the Tcplistenport property of each routine is consistent.
Make sure Web.xml has distributable properties
All session attributes must implement the Java.io.Serializable interface
The sample cluster installation has two Tomcat routines and one load balancing to allocate requests between servers. All three servers are running on a separate machine, and the following table lists the configuration parameters on the cluster and load balancing.
Edit Note: The values in the Web App directory above are wrapped to fit the layout. In your deployment, each value should be a single and complete line
Note: Do not set tcplistenaddress to 127.0.0.1, because 127 is used for loopback addresses and problems may occur during session replication.
Load Balancer Installation
The Tomcat server does not provide failover capability to redirect any incoming requests to the next available server when a cluster contact fails. So I use a separate load balancer to manage the load balancing of Web requests. There are some popular load balancers such as APACHE/MOD_JK, Balance, and Pen. I use pen as the load balancer in the sample cluster installation.
Pen is a simple, TCP-based protocol, such as a load balancer for HTTP or SMTP. He allows multiple servers to behave as a single server and automatically detects closed servers and assigns customers to the available servers. He provides load balancing and failure transfer capabilities. Pen is easy to install and configure, and is very easy to use and run on Windows and UNIX operating systems. The example configuration uses the Round-robin load balancing algorithm to allocate load balancing between cluster nodes
The command to run the load balancer is as follows:
Pen-r-a-f-D localhost:8080 192.168.0.10:9080 192.168.0.20:10080
The following is an explanation of each command-line parameter used to start the load balancer
-R: Using round robin load balancing
-A: Print data sent back and forth in ASCII format
-F: Stay at the front desk
-D: Debug mode is enabled
To find out more about the parameter details for starting the pen, visit the pen Web site
Figure 1 shows two cluster nodes, a load balancer, an instrumentation layer, and a test client topology
Graphic
Figure 1. Cluster Setup Diagram
Test Installation
I created a Web application called Clusterapp to validate the cluster installation and the session replication principle. To test the real session replication, I wrote a simple Java client language called Sessionreplicationclient to test the time it takes to copy session data from one server to another server. The client uses the Jakarta Commons httpclient condition frame to create and manipulate the HTTP session and invoke a servlet on the Tomcat server. The machine hardware and software configurations used to test session replication are as follows:
CPU:HP Pavilion Pentium III 800MHz
MEMORY:512MB RAM
Hard DISK:40GB
Operating System:windows Server
JDK version:1.4.2_05 (NOTE:JDK 1.4 or later version is required to use clustering and session replication)
Tomcat version:5.0.28
Tools:pen, log4j, Eclipse, Commons httpclient
When a replication client runs, he first sets a function command to manipulate the session such as adding a new attribute to the session, removing an existing attribute from the session, or invalidating a session. The client then invokes Replicationservlet by using the HttpClient and Postmethod classes in the Commons httpclient framework. Based on these session commands, the servlet generates a new seesion or modifies an existing session and turns to a Web page to look up the session details. If there are any errors in the admin session, go to an error page. I wrote a custom session listener class (Clusterappsessionlistener) for tracking the details of session management, such as creating a new session, modifying it, or terminating an existing seesion.
Chart 2 shows the session replication process
Graphic
Figure 2. Session Replication sequence Diagram
The session state on the server is tracked by a cookie for each Web request, so the request URL issued from the client must be the same in order to remain in use. In addition, a new HTTP session is created on each request. I used two types of test methods, based on the class of attributes added to the session, to test replication.
The first category has 100 lightweight objects (each 1K) added to the session. In the 2nd category, I added a single large object (100K) to compare the time spent in session replication based on the session property size
The following is a list of the test specifications for Sessionreplicationclient:
Number of client Threads: 2
Number of spin rings: 1000
Request delay: 1000 milliseconds
Test Example Number: 1000
Session properties: Small (100 1K objects) or larger (a 100K-sized object)
The command to run the test client with the specified parameters is as follows:
Java-dlog4j.configuration=log4j.xml com.clusterapp.test.SessionReplicationClient 2 192.168.0.10 9080 1000 1000 Lite
The test environment includes using a different session manager (Simpletcpreplicationmanager or Deltamanager) and session replication mode (synchronous, asynchronous, pool), The following table lists a series of test environments in the Tomcat cluster:
The Java tutorial you are looking at is: Session replication two in the Tomcat 5 cluster.
To change the copy mode from pool to synchronous or asynchronous, just modify the Replicationmode property value in the sender flag in the Server.xml file. Similarly, to change the type of the session manager, simply change the Managerclassname attribute of the cluster element.
The following parameters are used to compare the reaction time and the efficiency of Session replication:
Average reflection time (ms)
Average request time (MS)
Cluster overhead time (MS)
Replication Time (MS)
Ratio (BYTES/MS)
Ratio (bytes/request)
Test Results
Delta Manager and pool replication mode are used in conjunction with session replication efficiency is the best standard. Similarly, keeping the session size smaller can be 2 to 3 times times faster than copying a large session.
Replication Manager
Deltamanager is more effective at session replication because he only deals with session deltas instead of all session data. With Deltamanager, session replication efficiency can be increased by 30% to 50% (small sessions) compared to using simple Replication Manager.
Replication Mode
Compared to the other two options (synchronous and asynchronous), the pool replication mode replicates the session for a better time. During a replication time, the pool option is almost 4 times times faster than the agreed option. But in terms of reaction time and cluster overhead time, the pool and synchronization patterns are almost the same, because in synchronous mode, the cluster does not have to wait for Sessiong to complete replication before returning
Summary
Based on the results of the session replication test, we conclude that deltamanager should be used whenever possible. Because the overhead of replicating session data is significant, you must ensure that you do not store too much data in the session. Similarly, the size of the property added to the session is another factor that affects the session replication time. When I run a test to store a large object (100K) in session, the replication time is very high compared to storing small objects (1K) in session. The best way to minimize session replication overhead is to avoid invoking Session.setattribute () and storing the data in the request object rather than in the session. This is relatively better because the request attribute is reset when the Web request completes. Similarly, if there is no commercial reason to store the data on the server, we can store the data in the form of cookies on the client. This approach completely avoids the need to use any sessioin.
One way to minimize session replication time overhead is to limit the number of server routines in the cluster to two or three servers. This way, when the first server fails, the session data on the first server is copied to the second server. To keep the network open, clusters can be segmented into small groups, each consisting of two or three server routines. Remember that the more servers in the cluster, the more time the session replication takes. Currently TOMCAT5 does not support the concept of primary/secondary replication. will be available in later releases so that we will be able to store the session on one or two backup servers. With this feature, Tomcat will provide a more comprehensive method of session replication for running the Web server in a clustered environment.
Some attributes that Tomcat will support in the future:
Has the ability to have a property that is not serialized in the session, the cluster ignores the attribute
Has the ability to replicate the context properties and related data that is not serialized, such as JDBC connection pooling and object caches.
These features will make session replication in the Tomcat cluster stronger and more flexible.
I want to thank Filip Hanik for he valuable suggestions and feedback on the replication modes, session replication Web AP Plication Setup, and the test client sections of this article.
