cson  cson_sessmgr_whio_ht

ACHTUNG: THIS PAGE IS NOW MAINTAINED IN THE NEW WIKI: http://whiki.wanderinghorse.net/wikis/cson/?page=cson_sessmgr_whio_ht

See also: cson_session, cson_sessmgr_cpdo, cson_sessmgr_file, cson_sessmgr_whio_epfs

File-based Hashtable cson_session Storage

(Added 20110418.)

The "whio_ht" session manager is not compiled in by default, but if the library is built with it then this session manager provides session persistence via a hashtable file. Multiple processes may use the hashtable - it uses fcntl()-style locking, if enabled when the library is built and the underlying storage seems to support it. The hashtable keys are session IDs and the JSON session data are the hashtable values.

The configuration JSON object for the cson_sessmgr factory looks like:

{
   "file": "/path/to/file.whio_ht"
}

The hashtable file must already exist and be writable by the session-using process. The hashtables can be created programmatically, using the whio_ht API or using whio-ht-tool (which is also included in the session subdirectory of this source tree). For example:

~> whio-ht-tool sessions.whio_ht create

That will create sessions.whio_ht with an unspecified hashtable size (large enough for mid-sized uses). You can specify a specific hashtable size by passing hashSize NUMBER (ideally a prime number) as the last arguments.

Achtung: the hashtable has no way of recording the lifetimes of individual sessions. While whio-ht-tool can be used to remove individual sessions, or they can be removed programmatically, it is not generically possible to know which sessions have expired and should be removed. Thus this session manager implementation should not be used in high-traffic apps which might accumulate tons of old/stale sessions from various users/site visitors. We could wrap each session object in another object which records the timestamp, but then cleaning them up would require writing an app which loads and analyzes each session. Maybe someday i'll add that option (and the tool to clean up). On a related note, the hashtable can never shrink. Removed entries are marked as free and potentially recycled, but the storage itself is never shrunk.

Achtung #2: an untimely C signal while the hashtable is writing or flushing might leave it in a corrupted state. That could happen, e.g., from another thread or via a SIGPIPE in a CGI application. This client is responsible for ignoring/handling signals, if needed for his application.

We have all the pieces we need, in libwhio, to be able to compress the session data with zlib. Maybe someday i'll get bored and add that.