Page Comparison

When a single WSO2 product is providing interacting with a serviceweb application, a session object is created and remains in the memory of the WSO2 product. However, in a clustered environment, where you could have multiple WSO2 product servers fronted by a load balancer to balance the load among these products, the situation is a little different. If WSO2 server A does task X, WSO2 server B does task Y and WSO2 server C does task Z, and each one has a session object, there is no way for one WSO2 server to know what the other is doing. So, in order to synchronize between these servers, sticky sessions are used.

A sticky session ensures that all interactions with the WSO2 servers happens on one product server only even though there are other WSO2 product servers present in the cluster. So the session object will be the same for the duration of the interaction.

Image Removed

If the backend application is state-full, it may use sessions. Sessions can be managed in two different ways.

• Using sticky sessions: In this approach, once a session is created by the backend server, a session ID will be sent back to the client in the response message. This session ID will be tracked by the intermediate load balancers. If the user/client sent another request with the same session ID, that request will be sent to the same backend server.
•  Session replication: In this approach, backend servers will replicate the sessions among all the nodes in the cluster, and the load balancers will be able to send any request to any node.

This session can be implemented at the HTTP level or at the SOAP level. One downside of this approach is if a node has failed, the sessions associated with that node are lost and need to be restarted. It is common to couple this solution with a shared database solution. With sticky sessions enabled, the session data is kept in memory, but persistent data is saved into a database.

...