psy e48014c2e0 moved from https://github.com/epsylon/Elgg-Lorea-Hydra | vor 6 Jahren | |
---|---|---|
.. | ||
LRUCache.php | vor 6 Jahren | |
MemoryPool.php | vor 6 Jahren | |
MetadataCache.php | vor 6 Jahren | |
NullPool.php | vor 6 Jahren | |
Pool.php | vor 6 Jahren | |
README.md | vor 6 Jahren | |
SimpleCache.php | vor 6 Jahren | |
StashPool.php | vor 6 Jahren | |
SystemCache.php | vor 6 Jahren |
This document is primarily about the Pool
interface and implementations.
Why do we need our own caching interface instead of just deferring entirely
to a third party like Stash
or implementing the up-and-coming caching PSR?
I (Evan) have two reasons for this:
Typical interaction with a cache:
$info = $cache->get($id);
// Check to see if the cache missed
// It either didn't exist or was stale.
if ($info == null) {
$info = loadInfoFromDatabase($id);
$cache->set($id, $info);
}
return $info;
There are three things you have to get right every time you use the cache:
lock
to prevent cache stampedes (not shown)I was pondering if there was away to get around remembering and writing that logic every time. I think the solution is closures, which would allow us to do this:
$result = $cache->get($id, function() uses ($id) {
// Only executed on miss; also stores the result
return loadInfoFromDatabase($id);
});
We then provide a couple other typical-use methods for managing the cache.
This closure approach allows us to remove good chunk of complexity from the
Pool
interface, streamlining both use and maintenance.
Under the hood we just defer to Stash for the implementation details, but
dependent classes don't need to know this, since they just depend on the Pool
interface.