Session handling concepts

nevisProxy provides the concept of Dynamic Session Management Engine for session handling. The Dynamic Session Management Engine supports the definition of different session management rules for different applications and/or types of request. This makes it possible to provide a more flexible and fine-grained way of session handling than the previous Container Session Handling concept was able to offer.

A session is usually requested by a filter or servlet. If no filter or servlet in the chain requires a session, then no session will be created for the request and no already existing session will be associated with the request.

Benefits

The Dynamic Session Management Engine allows for a more flexible and fine-grained session handling. This paves the way for a higher session update granularity and makes a better adaptability to special application requirements possible.

Use cases

Among others, the Dynamic Session Management Engine provides a solution to the following problems:

• Constant background traffic (e.g., when using Ajax and/or some WebSockets solutions) can keep a session alive, even if there is no user activity. The Dynamic Session Management Engine is able to stop such "eternal" sessions.
• Some web pages contain a high volume of data and graphical material. If a user/browser sends a request for such a page, the initial request is followed by many subsequent requests for the graphical material, from the browser side. Each request for a picture, style sheet or java script will update the session and trigger a call to the session store. This poses a large performance problem to the session store if it is a remote, external database (e.g., MariaDB). The Dynamic Session Management Engine can prevent these unnecessary session updates.
• An organizational website can have secure parts and public parts. To avoid session exhaustion it is important to make the public parts safely session free. The Dynamic Session Management Engine can handle this challenge. The engine allows for the parallel existence of secured sessions as well as connections over session free paths at the same time.
• Customers with multi-tenant solutions might have different storage requirements per tenant. The Session Management Engine supports such mixtures of remote and local storage for multi-tenant solutions.
• The Container Session Handling can lead to unintended session overwrites when multiple requests of the same session run in parallel. In this case, the slowest request overwrites any updates done by the other requests. The Dynamic Session Management Engine deals with this problem by storing session data in name-value pairs, instead of in one data block. If the engine overwrites one data pair, all other session data remains unaffected.

Technical concept

In the Container Session Handling, the creation and handling of the sessions takes place in the servlet container. Consequently, there is only one storage and one set of session handling rules available for all sessions. With the Dynamic Session Management Engine, the session creation and handling is relocated to the filter chain level. Here, it is the SessionManagementFilter that creates a session for the respective filter chain.

If a session is needed, the SessionManagementFilter defines the method of session binding (e.g., by means of cookies) and creates the session. The storing and loading of the session is done by a session storage servlet. Depending on the required storage technology, a different session storage servlet is used.

Architecture

The Dynamic Session Management Engine makes it possible to configure a set-up with multiple session handling variations. The figure below shows an example architecture of such a set-up:

Note that a session is not persistent if it is created before the SessionManagementFilter (for example by a LuaFilter). Therefore, always place the SessionManagementFilter first in the filter chain, to avoid creating and using non-persisting sessions.