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