Locmem is not multiprocess nor threadsafe

[Tomáš Kopeček]

Documentation says that this cache backend is safe in multiprocess environment and also threadsafe. This probably not true.
a) multiprocess - it's complete nonsense - every process maintains its own cache object. So key found in c1 is not found in c2, also invalidation is impossible.
b) threads - problem is almost same - there is implementation of threadsafe writing/reading, but objects in threads are different so caches are different.

Solution:
a) Don't bother with this backend and say in documentation that is good only for development server or one htread/process servers, than it's completely ok to remove locking code.
b) Do it at least thread-safe (make some singleton object?)

[Malcolm Tredinnick]

For the multiprocess case, invalidation is the only possible issue here. The fact that there are separate caches for separate processes doesn't make it unsafe. A cache doesn't change the results, it just possible speeds things up. So if something is in the cache for one process and not for another, that shouldn't be a real issue. If it is, that object isn't cacheable in the first place (so what if one person sees a blog post 60 seconds before somebody else? It doesn't change anything). But invalidation might be a concern there.

(Removing 1.0 milestone, since that hasn't been determined yet)

[Jacob]

The locmem cache is perfectly safe it's just not very good -- each process and thread gets its own cache, so there's no chances of conflicts.

I've added this note to the docs; you'll see it when the doc-refactor lands:

Note that each process will have its own private cache instance, which means no
cross-process caching is possible. This obviously also means the local memory
cache isn't particularly memory-efficient, so it's probably not a good choice
for production environments.

[(none)]

Milestone 1.0 maybe deleted

[projectgus]

Would it please be possible to change the phrase "This cache is multi-process" to "per-process" (will attach possible patch.) Per-process seems to be a more accurate description of how the cache works.

I realise the subsequent paragraph explains it perfectly (thanks!), but there must be other idiot newbies like me who skimmed the docs before making a new admin command, thought "great, multi-process, no need to change anything!" and then wondered why their cache didn't invalidate cleanly. Before I, of course, RTed-rest-of-the-FM. :)

[projectgus]

Possible docs patch for LocMemCache "multi-process"

[chaobin]

The latest development doc as of writing this comment still has the original version. The locmem cache is a working solution, but a limited one.

In a multiprocess environment, typically such as httpd prefork mode, each forked process has its own cache object, which means the memory consumption of locmem is size(cache_object) * num_of_processes_forked. Also, in order for each process to be able to hit cache with a found value, it will first have to "warm" every cache object in each process by cache.set(), consequently, hit rates is also compromised, slightly.

Aside from those, locmem could be a good choice for a small project that wants some level of caching withsimplicity.

Still, the doc should have an additional note on this, or a link to this ticket.

[Tim Graham <timograham@…>]

In c37000ab04a1592ecb7436d45bd2b4b9d015c9b3:

Clarified that LocMemCache is per-process; refs #7639.

Thanks projectgus for the suggestion.

[Tim Graham <timograham@…>]

In f3cd0a009ec0ed4e705ee25c5fcf60f4c2ba02f8:

[1.6.x] Clarified that LocMemCache is per-process; refs #7639.

Thanks projectgus for the suggestion.

Backport of c37000ab04 from master

[Tim Graham <timograham@…>]

In a56773245b8926ddb73d957cf725aa83c5e5a9ea:

[1.7.x] Clarified that LocMemCache is per-process; refs #7639.

Thanks projectgus for the suggestion.

Backport of c37000ab04 from master

[Tim Graham]

I made the edit suggested by projectgus (by the way, opening a new ticket is a better way to get your suggestion noticed than commenting on a closed one).