What’s the problem with Session Replication?
Session replication can be used when multiple servers run the same program, and all require access to identical session information. For smaller applications, sessions are serialized following every request and then spread to other servers. For larger deployments, the session is de-serialized from a shared database at the start of each request. It is returned to the database after the completion of the process handling.
The primary issue is that the whole UI state must be serialized for this to function. The fundamental elements of Vaadin are serializable already; however, the app developer must also ensure that the classes they create are serializable. Any third-party classes indirectly or directly linked to the UI state must also be serializable.
Another issue can be that the amount of data in the UI state influences the time the process takes the session’s information and moves the data between servers. The size of one session is usually measured in several hundred kilobytes and, in some cases, even megabytes, based on the method used by the application to manage its data. Because the state is formulated in Java classes, which may have unrelated references to each other and therefore, there is no method of storing each piece independently and therefore only processing only those parts that actually changed.
In the end, every HTTP request to the Vaadin application can trigger some modifications to the session. Even in the simplest cases, where no part of the application is changed, there are internal elements like sequence numbers and timestamps that change. This is why it is crucial that multiple requests from the same session don’t get processed in the same way.
Vaadin utilizes the ReentrantLock instance, which is saved within the HTTP session to ensure that the UI state isn’t accessible by different parties simultaneously. The lock is automatically retrieved to handle requests on a regular basis as well as when making use of UI.access(). ReentrantLocks only can be used when everything that is associated with a particular session is separated from one JVM. In the case of a session replicated across multiple servers, concurrent access should be controlled in a separate manner. Particularly a distributed lock for particular sessions is required prior to de-serializing the session’s information.
This means that all generic “transparent” session replication solutions can’t be used. It is required to develop a solution specific to Vaadin and make modifications to avoid the built-in feature of ReentrantLock. With those modifications, the development of applications becomes more complex and the user will experience increased latency.
Scale Out Using Sticky Sessions
The most common reason for using sessions replication can be used to manage multiple simultaneous users by operating the application on different servers, using a load balancer which distributes requests among the servers. The most straightforward approach at an abstract level is to have the load balancer allocates every request to a server without analyzing the content that the user is requesting. This is why it calls for session replication.
An alternative to replication of sessions is to use a sticky sessions. It means the load-balancer will look at the session ID cookie on every request, and then uses it to determine which server will take care of the request. So every request associated with a particular session is handled through the exact same server meaning there’s no need for re-running sessions. The load balancer will select any server that is available for requests that don’t yet have a session ID cookie or when the load balancer is aware that the session being questioned has expired.
In some instances an alternative approach could be employed. Vaadin is capable of handling a large number of simultaneous users, as long as the business logic that is triggered by each user does not consume excessive server resources. Therefore, instead of load balancing the entire application, it may be better to store your UI state on one server, but spread the logic of the application across several servers. So servers running Vaadin requires sufficient memory to manage every concurrent session, but the CPU and I/O capacity required for business logic could be easily scaled up.
They can also be useful in the case of session replication. If the request is sent to the server that was most recently utilized the session in question, the server will be able to use the session that was previously used without needing to download the most current version from a different location.
Leave a Reply