Session cache

In conjunction with load balancing, a session caching system operates to optimize network bandwidth usage and the allocation/deallocation of resources on the HSM and the application server. When the application requests that the session be terminated by the HSM, 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 certain 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 upon the next session opening.

Characteristics of the session cache:

1. Intra-process: caching is done per process. This means that 2 applications on the same machine will each have a cache, without sharing sessions between the 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 you only need to enable an environment variable. No changes to the application's source code are required.