In the last blog post I've talked about the technicallies of running Wicket clustered.

But there are more things to consider. 

The session handling of server based web applications is usually done by the web application server which in the Java world runs on top of a Servlet container.
This might be Jetty, Tomcat or some comercial one.

The Servlet specification contains the session and cookie handling.
Since Wicket runs on the application server, it doesn't itself has to deal with storing and loading sessions. This is all done by the application server.
Wicket just 'uses' the session that the application server provides.

In a cluster environment it is also the responsibility of the application server to create an environment where it replicates the session.

As outlined in the previous article it is possible to follow certain best practices to help Wicket keep the session small, like using LoadableDetachableModel's.

But the application server relies on a certain level of reliability of session stickiness of the load-balancer.
Looking at the technology stack there are just too many drawbacks when we have to assume a none-stickiness, or when this doesn’t work reliably.

There usually are a few scenarios how the session replication can work.

If the session is stored in a database that all cluster nodes can use at the same time it might be possible that the application works without LB session stickiness.
But this is quite a performance hit since there is usually a long way to the database and the session data has to be serialized and deserialized.
In this scenario you cannot really use the second-level cache of the application server because session data might differ slightly when switching from one cluster node to another in a rapid succession.

It is also possible to store the session in memory using a technology like Hazelcast, Apache Ignite or something like that.
In this scenario the session is stored locally in a second-level cache and then replicated in the background to other cluster nodes.
However the session replication might not be immediate. Which means that a non-stickiness will not properly work here. Because the session might not have replicated when the LB switches nodes during a request which will lead to unexpected behavior or page load errors.

So it is highly recommended to use the application servers second-level cache for performance reasons and use session stickiness of the load-balancer.
To avoid SSL offloading load-balancers usually also can be configured to use certain nodes on an IP address or region basis.

For more info take a look here: lost_in_redirection_with_apache_wicket