Cache: APC and files don't delete the same thing

[yoyopuyo]

File Cache deletes all the subdirectory
while APC Cache does not.

Eg: if you call Cache::delete_all( 'cache/users' ), the file version will delete 'cache/users/0' and ''cache/users/1'
Not the apc version

[jschreuder]

For APC/Memcached we added a bit of functionality that is meant to mimic directories in the filesystem, it adds a bit of overhead on write but should make the type of deletions you mentioned possible. There's however one possible problem: APC doesn't guarentee persistance of the entries in it, when your cache is full "old" or unused values are deleted take make room for new ones. Thus the actual truth of the matter here is that APC is less fit for deleting specific sub-caches.

Part of the question here is if your APC cache isn't too small and possibly deleted the dir caches. And if that's the case the question should be whether we should keep this functionality at all for APC as it can't be relied upon to work...

[aronrosenberg]

We found a very nasty race condition / design flaw with the memcached implementation of this directory mimic functionality. Inside fuel's memcached implementation, there is no consistency handling for the DIR and base index entries so if two servers are concurrently reading the current store, appending a new key, then writing the result, they will clobber each other and a key from one (or multiple) will get lost.

The only way around this would be to implement the cas functions with serial number and conditional write that key only if the serial number is still the same. If the write fails, then re-read and re-append new key and loop until that is successful.

Even better would be to provide a way to disable the whole key caching code since it introduces a severe penalty of 2x to every read and write operation.

[WanWizard]

It has never been designed for multiple server access, so this is a good point that needs to be addressed.

I'll move this to the 2.0 roadmap, when we need to refactor the Cache code anyway.