-
totten authored
Overview ---------------------------------------- When using forms based on CiviQuickForm (specifically `CRM_Core_Controller`), `CRM_Core_Session` stores form-state via `CRM_Core_BAO_Cache::storeSessionToCache` and `::restoreSessionFromCache`, which in turn calls `CRM_Core_BAO_Cache::setItem()` and `::getItem()`. However, using `CRM_Core_BAO_Cache::setItem()` and `::getItem()` means that all session state **must** be written to MySQL. For #174, we seek the **option** to store via Redis/Memcache. Before ---------------------------------------- * (a) Form/session state is always stored via `CRM_Core_BAO_Cache::setItem()` and `civicrm_cache` table. * (b) To ensure that old sessions are periodically purged, there is special purpose logic that accesses `civicrm_cache` (roughly `delete where group_name=Sessions and created_date < now()-ttl`). * (c) On Memcache/Redis-enabled systems, the cache server functions as an extra tier. The DB provides canonical storage for form/session state. After ---------------------------------------- * (a) Form/session state is stored via `CRM_Utils_CacheInterface`. * On a typical server, this defaults to `CRM_Utils_Cache_SqlGroup` and `civicrm_cache` table. * (b) To ensure that old sessions are periodically purged, the call to `CRM_Utils_CacheInterface::set()` specifies a TTL. * It is the responsibility of the cache driver to handle TTLs. With #12360, TTL's are supported in `ArrayCache`, `SqlGroup`, and `Redis`. * (c) On Memcache/Redis-enabled systems, the cache server provides canonical storage for form/session state.
19707a63