ChainCache save value with infinite lifetime when propagate to fastest cache about cache HOT 9 CLOSED

Tricky. I think that setting a default TTL (default null) is a good idea here, as data fetched and kept "hot" is not necessarily always fresh.

Thoughts @doctrine/doctrinecore?

from cache.

mmm, just encountered this issue and it is actually quite "severe" right? It might also explain some crazy behaviour I have encountered for which I usually resorted to using a "TTL-specific" cacheEntryIdentifier...

Description
Mainly for my own understanding, a short description with an example.

Imagine an application running somewhere in the cloud, which typically reboots once every 24 hours with the following ChainCache:

• fast and volatile: is cleared on each server restart
• slow and persistant

Now suppose :

• a cache entry X is saved to the ChainCache with a TTL of 4 hours
  • cache entry X is saved to the fast cache with a TTL of 4 hours
  • cache entry X to the slow cache with a TTL of 4 hours
• the server is restarted, clearing the fast and volatile cache (APCu)
• cache entry X is looked up
  • cache entry X is not found in the fast (APCu) cache
  • cache entry X is found in the slow cache
  • cache entry X will be propagated to / stored in the fast cache with infinite TTL
• after 4 hours, cache entry X is looked up again
  • cache entry X is found in the fast (APCu) cache and used, potentially leading to strange behavior
• ... repeat, repeat, repeat using invalid cache entry until next server restart

Possible solutions
As suggested here #246 (comment), the second proposal of trying to determine the remaining TTL would be the most elegant, but quite challenging to implement for all various CacheProviders. Maybe we can check whether a CacheProvider implements a specific interface like:

interface RemainingTimeToLiveAwareCacheProvider
{
	public function getRemainingTimeToLiveInSeconds(string $cacheEntry): int
}

In case a CacheProvider does not implement such interface, we can fall back to solution number 1: allow to define a default TTL for the ChainCache, which defaults to null, but can be set to a relative short periods to prevent problems / strange behaviour, but does increase the load on the slow cache...

Approach
A viable approach might be to first start with the default TTL which can be set upon ChainCache initialization. And THEN come up with the interface?

Note that Symfony can be used as inspiration, it uses:

• the default TTL
• a CacheItem which carries the lifetime as a property

from cache.

I'll try to backport your fix to 1.10.x branch and cut a new release this evening :)

from cache.

For proposal 2, many backend don't have a getter to retrieve the remain ttl.
A quick solution could be to wrap the cachedData in an object containing the {cachedData, ttl}.
But it will prevent to reuse the same Cache server without instancing a ChainCache as the stored data is not in the same format.

Without a new elegant solution on proposal 2, not sure it's worth it.

from cache.

Anyone got feedback on the suggested approach?

from cache.

@Ocramius this issue:

• was fixed in #335
• was released in https://github.com/doctrine/cache/releases/tag/1.10.1
  • without mentioning it in the "release notes"
• and can be closed

from cache.

Thanks for the heads up!

from cache.

@malarzm sorry, I misread this page:

1.10.1...master

1.10.1 was tagged on 27-05-2020 and #335 was merged one day later 28-05-2020, so it was not included in 1.10.1

So I think this issue needs to be re-opened until new release is tagged? Probably a patch version 1.10.2 suffices?

from cache.

@beberlei can you have a look at this? Been trying to solve quite a serious bug since #246 (comment), only think remaining is tagging it in a new release...

from cache.