Session Cache

A session caching system works in conjunction with load balancing to optimize network bandwidth usage and the allocation and deallocation of resources on the HSM and the application server. When the application requests that the HSM terminate the session, it is logically terminated (from the application’s perspective, the session has been successfully closed); the HSM library (loaded into the application process’s address space) maintains the physical session with the HSM for a specified period of time; if a new session is requested, the library reuses that physical session (re-authenticating the user locally). Reusing an already established session provides a performance benefit by avoiding the need to renegotiate the physical session, especially if the application is using encrypted sessions (TLS). The type of the new session (unencrypted or encrypted) must match that of the existing physical session. If the cached physical session is not reused within the timeout period, it is physically terminated the next time a session is opened.

Info

If the network timeouts (send and receive) are shorter than the session cache timeout, the shorter one will take precedence to prevent inactive sessions from being returned.

Features of the session cache:

1. Intra-process: The cache is implemented per process. This means that two applications on the same machine will each have their own cache, without sharing sessions between processes;
2. Centralized: implemented in the HSM library. This way the cache is enabled at a central point and all other libraries dependent on it inherit the functionality;
3. Transparent: To enable session caching, only an environment variable needs to be activated. No changes to the application's source code are required.

For details on configuring the session cache, see the " Sessions - Session Cache" topic.