type="StorageService", this session cache implementation stores session data using a previously-defined
<StorageService> plugin. It has a hybrid design that also buffers frequently-used sessions inside the web server processes as they come and go, to minimize repeated transfers of data across the process boundary. Memory use can be tuned.
The implementation also divides its storage needs into two classes, which for historical reasons the author doesn't even remember, are termed "light" and "not light". The practical difference is that operations related to making SAML logout work are termed "light" and can be diverted to a separate storage back-end by specifying the
What makes the name confusing at this point is that, in practice, you might use this to actually divert the logout storage operations to a heavier option like a memcache or database service because they have to be visible across a cluster for logout to be useful, whereas the standard session store might just be left local and in-memory. The name essentially refers more to the fact that the logout-related operations will be less frequent.
Attributes specific to this type include:
Reference to the
|XML ID||Reference to the |
|time in seconds||900||Interval in seconds between background cleanup of the in-web-server cache of frequently used sessions. The underlying storage service may have a separate setting in its own right to regulate its own cleanup.|
|time in seconds||900|
Period of inactivity after which unused sessions can be deleted from the in-web-server cache. Set to a higher value to increase performance and memory usage, or a lower value to decrease memory usage and performance. This setting only adjusts performance trade-offs and does not cause any sessions to be purged from underlying cache storage.
|boolean||false (true for legacy configurations)||Determines whether to store copies of SAML assertion(s) supplied during the creation of the session. Can usually be turned off to save memory and improve performance of cache.|
If set, the cache will look for the session key in the specified HTTP request header in addition to a
|string||If set, the cache will return a created session key in the specified HTTP response header in addition to a |
|boolean||true||Determines whether the cookie-based session recovery feature is willing to overlook failed storage operations to see if a session might have been revoked by a logout.|