Menu
I was trying to decide what is better in a Tomcat+Apache reverse proxy mode for session replication. What is more common on deployments? session replication or stick session? Are there any drawbacks for session replication?
Thanks
389
Tomcat provides in-memory session replication through a combination of serializable session attributes, "sticky sessions", which are provided by the load balancer, and specialized components configured in Tomcat's XML configuration files. We'll tackle each of these components one by one.
Session replication is a mechanism used to replicate the data stored in a session across different instances. However, the replicated instance must be part of the same cluster. When session replication is enabled in a cluster environment, the entire session data is copied on a replicated instance.
The DeltaManager manages replicated sessions by only replicating the deltas in data. For applications written to handle this, the DeltaManager is the optimal way of replicating data. This code is almost identical to StandardManager with a difference in how it persists sessions and some modifications to it.
I can point out the following considerations if you go for session replication.
Performance
The main drawback will be on performance. Replicated sessions involve copying of session data over to all the servers in the cluster. The more servers you have in the cluster, the additional overheads involved.
Tomcat helps with this overhead by definining two modes for session replication.
DeltaManager (default) and BackupManager
From this URL http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
Using the above configuration will enable all-to-all session replication using the DeltaManager to replicate session deltas. By all-to-all we mean that the session gets replicated to all the other nodes in the cluster. This works great for smaller cluster but we don't recommend it for larger clusters(a lot of tomcat nodes). Also when using the delta manager it will replicate to all nodes, even nodes that don't have the application deployed.
To get around this problem, you'll want to use the BackupManager. This manager only replicates the session data to one backup node, and only to nodes that have the application deployed. Downside of the BackupManager: not quite as battle tested as the delta manager
Read this URL for good design tips for the cluster if enabling session replication.
Memory
How many concurrent users will be hitting the application? the more users, the more data gets stored into sessions, and hence an overload for session replication.
Code considerations
Additionally you need to ensure the data being put into the session by the application is serializable. Serializing session data has some overhead for replicating the session state. It's a good idea to keep the session size reasonably small, so the developers need to check the amount of data being put into the session.
Sticky Sessions
Given these considerations, it actually depends on the criticality of the use cases. If you go for sticky sessions alone, then there is a chance of loss of user data during a critical journey.
Do you have means to recover from that - eg: by persisiting critical data into database at each step of a order or payment journey? If not the user has to login and start again. This is fine for websites which are not transactional, but browse brochureware type of data or filling out forms to capture data which is not payment etc.
63
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
