Opened 16 years ago

Closed 16 years ago

Last modified 10 years ago

#7639 closed Uncategorized (fixed)

Locmem is not multiprocess nor threadsafe

Reported by: Tomáš Kopeček Owned by: nobody
Component: Core (Cache system) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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?)

Attachments (1)

0001-Clarify-LocMemCache-being-per-process-Refs-7639.diff (796 bytes ) - added by projectgus 13 years ago.
Possible docs patch for LocMemCache "multi-process"

Download all attachments as: .zip

Change History (11)

comment:1 by Malcolm Tredinnick, 16 years ago

milestone: 1.0

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)

comment:2 by Eric Holscher, 16 years ago

milestone: 1.0 maybe
Triage Stage: UnreviewedDesign decision needed

comment:3 by Jacob, 16 years ago

Resolution: fixed
Status: newclosed

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.

comment:4 by (none), 16 years ago

milestone: 1.0 maybe

Milestone 1.0 maybe deleted

comment:5 by projectgus, 13 years ago

Easy pickings: unset
Severity: Normal
Type: Uncategorized
UI/UX: unset

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. :)

by projectgus, 13 years ago

Possible docs patch for LocMemCache "multi-process"

comment:6 by chaobin, 10 years ago

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 with simplicity.

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

Last edited 10 years ago by chaobin (previous) (diff)

comment:7 by Tim Graham <timograham@…>, 10 years ago

In c37000ab04a1592ecb7436d45bd2b4b9d015c9b3:

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

Thanks projectgus for the suggestion.

comment:8 by Tim Graham <timograham@…>, 10 years ago

In f3cd0a009ec0ed4e705ee25c5fcf60f4c2ba02f8:

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

Thanks projectgus for the suggestion.

Backport of c37000ab04 from master

comment:9 by Tim Graham <timograham@…>, 10 years ago

In a56773245b8926ddb73d957cf725aa83c5e5a9ea:

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

Thanks projectgus for the suggestion.

Backport of c37000ab04 from master

comment:10 by Tim Graham, 10 years ago

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).

Note: See TracTickets for help on using tickets.
Back to Top