Session management with SCACHE
Scache is alternate approach to session handling. It provides simple key-value storage to use for transient session data storage, but in tree-structured form where you can access only required parts and also delete and expire whole subtrees when required. Scache mimics filesystem with atomicity between clients.
Scache is not cache. Unlike for example memcache, it's guarantees to store all data inserted in complete and only expire session in complete on deliberate or error situations, so that application can rely all session data be available or all session data gone. Scache tries to combine $_SESSION -type reliable storage with memcache-type key-value shared cache with some extra possibilities that tree-structured storage offers.
Functions for session initialization, opening, connecting, renaming and dropping. Sessions are distinguished and opened by client generated session identifier.
Private session storage
Session storage is private save space unique to every session. Session storage is persistent over lifespan of session. Generally session storage is for keeping per user private information and collected per user data sensitive to active login.
Shared counters are path/key addressable atomic 64-bit integers on scached backend common to all sessions assigned on same partition. Shared counters can be generally used for inter session communication, specifically as advisory triggers.
Shared storage equals to private session storage, but is common and mutually accessible to all sessions residing on same partition. Unlink cache storage described below shared storage never expires stored data until deliberately ordered to. Shared storage can be used for inter session communication with optional aid of shared counters.
Cache storage is path/key addressable shared storage common to alle sessions on same partition. Unlike shared storage above, cache expires data exceeding configurable memory limit.
Ring storage is double linked circular datatype on scached backend. As like other data operations, rings are addressed by path-prefixed keys. Each key contains one ring, which can be operated with functions below.
Rings are shared resource common to all connecting clients assigned to same partition. Values stored to rings are persistent. All data queued to ring must be eventually purged to avoid memory leaking.
Rings are mainly for implementing FIFOs, LIFOs and producer-consumers -workqueues.
Miscellaneous utility functions.