Session Store Setups

Depending on the required session storage technology, nevisProxy calls for a different session store servlet. Currently, the following solutions are supported:

• Local storage of a session via the LocalSessionStoreServlet
• Remote session storage in a PostgreSQL database by means of the PostgreSQLSessionStoreServlet
• Remote session storage in a MariaDB database by means of the MySQLSessionStoreServlet
• Hybrid session storage as the combination of a local and a remote storage, with the MultiLevelSessionStoreServlet

Each session store technology has its advantages and limitations.

For example, as the MySQLSessionStoreServlet uses a remote database, sessions are preserved in case a nevisProxy instance is restarted or becomes unavailable for some reason. The remote session store technology is also capable of session replication between two database instances, and of sharing the stored sessions between nevisProxy instances. This is therefore the only session store technology that does not require a session-sticky load balancer if multiple nevisProxy instances are used together. Depending on the concrete setup, this solution can handle multiple nevisProxy node failures, or even database node failures, if replication is enabled. However, the solution also results in an overhead when accessing the sessions, because of the communication delay between the proxy and the DB, and the extra time needed for the DB to look up a given session. Therefore, this solution best suits use cases with high redundancy requirements, where no higher load is expected.

The LocalSessionStoreServlet, on the other hand, is suitable when high load is expected and session redundancy is not a requirement. As this solution stores the session information in a local memory, it is optimized for good performance. On the other side, if a nevisProxy instance fails, all sessions stored on that instance are lost. Another limitation is the need for a session-sticky load balancer, if the setup includes multiple nevisProxy instances. The session-sticky load balancer must guarantee that all subsequent requests in a session created on a given instance, go to the same instance during this particular session.

To combine the advantages of the above two solutions, the hybrid session store was introduced. It uses a LocalSessionStoreServlet to initially store the session information for good performance, while on a backup thread the local sessions are saved into a remote database, for high redundancy. This allows for high performance and high redundancy at the same time: If a nevisProxy node fails, another one can take over its sessions by accessing them in the remote database. But because the hybrid solution includes a LocalSessionStoreServlet, it still needs the session-sticky load balancer in case of multiple instances.

The following table summarizes the advantages and limitations of the different session stores:

	Local Session Store	Remote Session Store	Hybrid Session Store
Performance	High	Normal	High
Redundancy	Low	High	High
Session-Sticky Load Balancer****(in case of multiple instances)	Required	Not required(but improves performance)	Required

Choosing a session store for clustered and Kubernetes deployments

The Hybrid Session Store's local cache and terminated session polling (EnablePollTerminatedCalls, see Terminated session polling) cannot be combined reliably: a termination event can be consumed by a nevisProxy node other than the one holding the session, so the session is not invalidated where it matters. This is independent of the remote store technology used as the backup (MariaDB or PostgreSQL).

When deploying multiple nevisProxy instances, choose based on your priority:

• Reliable backend-triggered session termination (for example, a session kill triggered by a backend application through a nevisAuth REST call, or through nevisAdapt): use the PostgreSQLSessionStoreServlet or MySQLSessionStoreServlet exclusively. Every node resolves sessions from the shared database, so a termination written by one node is immediately visible to all others.
• Maximum performance and session throughput: use the MultiLevelSessionStoreServlet, but do not enable terminated session polling. Rely on other mechanisms instead, such as shorter session inactivity timeouts or client-side/front-channel logout.

This trade-off also applies to Kubernetes deployments with multiple nevisProxy replicas: the local cache used by the MultiLevelSessionStoreServlet is pod-local state, so the same choice between throughput and reliable centralized termination applies there as well.