This still rely on APC backward compatibility of APCu where all apc_* functions internally call apcu_* functions. APC backward compatibility is included by default for APCu on PHP5.5 and PHP5.6. But for PHP7, APC backward compatibility is not included by default (and still not working on Windows). Any chance to update the APC driver to check for existence of apcu_fetch function and if so use the apcu_* functions with fallback to apc_* functions? Similar to https://github.com/illuminate/cache/blob/master/ApcWrapper.php

See https://github.com/tedious/Stash/pull/256

The main purpose for this feature is to be able to invalidate cache entries and automatically invalidate other cache entries that are dependent from each other. Generally "Grouping" and "Namespacing" are good ideas but not suitable for the most use cases.

Problem

Let´t take the example of a simple one-to-one relation. We have a Brand and a Product. Both are models in some relational database. On the website we want to build a product presentation that looks like this

$view = sprintf("%s by %s", $product, $brand);

Now if we want to cache the view, currently neither namespacing nor grouping could help us invalidate the view, if it was cached and either product or brand changed.

a general approach to cache all the items would be

cache($product, "models/product/1")
cache($brand, "models/brand/1")
cache($view, "view/1");

if than a $product or $brand changes, both need to now exactly who used them, to be able to invalidate also $view as it would otherwise display invalid out-dated data.

Solution

I will call my solution Dependency Inheritance and Cache Invalidation. Basically the Stash\Interfaces\ItemInterface gets one new method addDependency

/**
 * Adds an ItemInterface as dependency. If the added
 * item gets invalidated, the caller also gets invalidated.
 * If $inherit is true, hierarchical dependencies are enabled.
 *
 * @param ItemInterface $dependency
 * @param boolean $inherit if dependencies should be inherited
 * @return boolean
 */
public function addDependency(ItemInterface $dependency, $inherit = true);

A dependency is nothing more than an instance of Stash\Interfaces\ItemInterface. Therefore it is able to hierarchically depend on many different items. This enables us to invalidate one deeply nested cache item. This would also invalidate the root element, but not all untouched siblings. So that the root has to refetch only really missing cache items and the rest can be used from already cached items.

Under the hood my solution uses the same technique as the grouping mechanism. It takes a cache key and combines it with the dependent in the following way

$key = array_merge([$dependency->key, $this->key])
// ==> model/foo/1/model/bar/2

This key is saved with a value of 1 the same way the stampede protection is saved. Then the new dependency $key is added to a list of dependencies into the items record array.

The next time, when a cache item is fetched, the validation process also gets the dependency keys, fetches them using a multiGet and checks if the response count is the same as the count of the dependency keys. If any model that was saved and invalidated, everything in its group (Model/Product/ID/*) gets also deleted. This way not all dependency keys would be fetched and the count would mismatch. Bingo, we invalidated everything that depends on that item.

So the example from above would look like this

Cache Key : Model/Product/1
Attributes: {
                "name": "My Product"
            }

Cache Key : Model/Brand/1
Attributes: {
                "name": "Great Company"
            }

Cache Key : View/ProductPresentation/1
Attrbiutes: {
                "text": render(sprintf("%s by %s", cache("Model/Product/1"), cache("Model/Brand/1")))
            }
Dependency: [
                "Model/Product/1/View/ProductPresentation/1",
                "Model/Brand/1/View/ProductPresentation/1"
            ]

This resolves issue #350

When using the FileSystem driver on a system where opcache.restrict_api is defined in php.ini, stash throws a fatal error on save. With this change, we check that ini setting before attempting to clear cache.

This is a bit of a long story.

I've been working with tedivm/Stash for a while for an Authentication and Authorisation library. I was using the FileSystem driver for file based sessions. It was working for a long time, both from a Windows computer and on hosted Ubuntu system on Digital Ocean.

However I recently started testing it on my Ubuntu VM which runs on the same kind of specs as the Digital Ocean's VM in order to simulate a closer environment to production.

And then the session management broke.

I started logging everything to figure out what was happening. And what was happening was this, but let me describe the context first.

<?php 
/* Cachekey: cache/polyauthqkc1z5m33e/ */
/* Type: array */
$expiration = 1394941347;
$data = array();

/* Child Type: array */
$data['return'] = unserialize(base64_decode('YToxOntzOjc6InVzZXJfaWQiO2I6MDt9'));

/* Child Type: integer */
$data['createdOn'] = 1394901250;

Here is the included file (cached file). The returned variable should end up being: ["user_id" => false];

I know this is the real file content prior the the include command because I wrote this as a part of my logger:

//...line 141
\FB::log(file_get_contents($path), 'FILE CONTENT PRIOR TO INCLUSION');

include($path);
//...etc

And it showed the above file content exactly prior to inclusion.

Now the next thing I did was log the $data variable.

//...line 141
\FB::log(file_get_contents($path), 'FILE CONTENT PRIOR TO INCLUSION');

include($path);

\FB::log($data, 'DATA VARIABLE');
//...etc

This is where the discrepancy appeared.

On my Windows (Apache + mod_php) system it showed:

       "data"       => [
           "return"    => [
               "user_id" => false
           ],
           "createdOn" => 1394901250
       ]

On my Ubuntu Digital Ocean VM it would show the same since the session management was working.

However on my Ubuntu VirualBox VM it would show:

       "data"       => [
           "return"    => [],
           "createdOn" => 1394901250
       ]

Exactly the same createdOn timestamp, but an empty return array!?

Needless to say, this made session management impossible, since none of the sessions could ever be remembered.

Now the error goes away, and still works with all environments, if you instead use eval with file_get_contents:

eval('?>' . file_get_contents($path));

This technique is exactly equivalent to using include (the ?> basically allows the file to start with <?php). See this: http://stackoverflow.com/questions/1184628/php-equivalent-of-include-using-eval

I don't know why this error occurs. I don't have enough knowledge about the PHP internals why include doesn't work but this does. It might have something to do with opcode or caching.

I also did some benchmarking. Zero microtime difference.

As described in #365, Stash can currently run into a fatal error in specific circumstances.

This PR introduces a check in Apc->isAvailable() to let the driver fail early if APCu is not configured to run in CLI environments.

I am looking for a way to globally disable cache for a pool, for use during development.

I was hoping something like $pool->disable() would exist, which would then simply force isMiss() to return true, so that the operation happens always.

This would mean that regardless of the timeout time, it would be ignored.

Stash v0.10.1 on windows fails with the following error.

Message: touch() [function.touch]: Unable to create file C:\wamp\www\clickfortime.com\httpdocs/application//cache/1952a01898073d1e/561b9b4f2e42cbd7/a8b72798beb911ae/98c8c8907d45950a/b2eb734903575495/3b57a32e2841bda5/dc960c46c38bd16e/953d97cdeefdbc68/e9772a20f09b5d13/28a579892c11a4c8/cfcd208495d565ef/66e7dff9f98764da.php because Invalid argument

My best guess is because it is not using the correct path directory separator.

Currently Stash can't easily support multiple distinct cache spaces due to the potential for a collision in the memory handler. In order to improve this, the static in-memory handler should be replaced with an optional use of the Array handler stacked upfront in the Multihandler.

I have a situation where there may be race conditions in the cache. That is when multiple requests are sent to the server, each one may manipulate the cache at the same time. Is there way to lock the cache item per process and make them evaluate one at a time after the previous lock opens?

Memcache (without "d") connections are persistent by defautl. In order to save resources (new TCP/IP sockets for each HTTP requests) for both backends I propose to make Memcached connections to be persistent by default. To keep configuration easy and clean persist_id is calculated automatically based on servers list and options array (any change to options will cause persist_id change). #313 Can be resolved by this pull request.

With heavy use of Stash creation of Item classes & setKey shows up in profile data, so the change tries to reduce function calls in these.

Suggested followup is executeGet(). Note: Might need another pass on this tomorrow for CS / tests if this is otherwise accepted. Note2: Contains interface change on Item to force array type on $key, felt like a easy way to avoid having to check.

Due to difference in SessionInterfaceHandler interface in PHP 7.x and PHP 8+ gc method return type was ommited and suppressed warning as PHP 8+ It's better for future to make different version of Stash for PHP 7.x and PHP 8+

Minor change was made also to remove cmpatibility with PHP version before 5.4.0 while Stash package is compatible with 7+.

Stash cache from version 0.17.0+ and later require PHP 7+, but there are union type declaration which is available as of PHP 8.0.0. This lead to syntax error in PHP 7+ environments!

https://github.com/tedious/Stash/blob/a2c9df16c77b13e1f90462f30597a772166eea8f/src/Stash/Session.php#L229

I suggest to use mixed return type and update PHP doc header.

I'm getting "Serialization of Closure is not allowed" in concrete5 which uses Stash. This happens because objects stored in or returned by Empheral are a reference and any changes to the original/returned item also alters the stored instance in cache. Therefore requesting the same cached item twice might result in different returned values even though the key has not been altered through a regular Stash set function.

This might be intended behaviour, although I don't feel it is really intuitive. It was suggested in the issue (concrete5/concrete5#6113) that this could be something that can be changed in Stash as well.

footnote: concrete5 clones objects before caching in Stash, but retrieves the cached instance without cloning. So the problem is less apparent there.

If i use the lock method, the cache system creates an empty folder. Is that normal? This is my setup:

$objCacheDriver = new \Stash\Driver\FileSystem(
[
	'path' => $this->objConfig->get('cache.file.path')
]);

$objCache = new \Stash\Pool($objCacheDriver);

$objCacheItem = $objCache->getItem('product.1233.444.555');

$mixCacheData = $objCacheItem->get();

if ($objCacheItem->isMiss())
{
	$objCacheItem->lock();

	$mixCacheData = 1337;

	$objCacheItem->set($mixCacheData);

	$objCache->save($objCacheItem);
}

We use Concrete5 to build sites and it uses Stash. I've got an issue on a site where we have large strings in the cache file and I get errors like: "PHP Warning: Unterminated comment starting line 16 in /home/www4x90/public_html/application/files/cache/0fea6a13c52b4d47/25368f24b045ca84/38a865804f8fdcb6/57cd99682e939275/18e23c785c6a72cf/ca47fbe20fed45aa.php on line 16"

There is not an unterminated comment, the code is fine. I think the issue is that maybe the stash parser is not reading the entire file?

I've attached a problem php cache file. Is the file too long to be passed? Is there a fix? ca47fbe20fed45aa.txt