3 ms·

Took a look at the Django Cache Machine they mention, at the invalidation scheme (http://jbalogh.me/projects/cache-machine/#cache-manager http://jbalogh.me/proj

by zzzeek 15y ago

Took a look at the Django Cache Machine they mention, at the invalidation scheme (http://jbalogh.me/projects/cache-machine/#cache-manager http://jbalogh.me/projects/cache-machine/#cache-manager). It stores a "flush list", linking objects to their originating, cached queries. Interesting, though looks like something that could get out of hand quickly - are they storing the "flush list" itself in the cache (else how do all nodes learn of the invalidation) ? That's interesting, though a little creepy (the list gets very large as they appear to be keying on the SQL itself ?) Then they have the invalidation flow along all the relationships - maybe that's OK, but maybe it leads to a lot of excessive invalidation. Also they have a notion of how to avoid a certain kind of race condition there, caching ``None`` instead of just deleting, but it's not clear to me how that helps - you really need a version ID there if you want to prevent that particular condition (else thread 1 puts None, thread 2 sees None, OK we'll put a new one there, thread 3, which started before all of them, doesn't see the None, puts stale data in). Really if you're caching SQL queries and such, you really, really should be doing little to no modification of cached data - this library makes it seem "easy" which it's not.

bjpless 15y ago
Your point is well taken; however, as the writer of the article, I'd say this. Our business requirements dictate that slightly inconsistent data is acceptable in certain circumstances. We would not retrieve objects through the caching flow in situations where absolute data integrity is required. That points makes all the difference, in my mind. To your point about excessive invalidation, that depends on your Read/Write workload.
- zzzeek 15y ago
  well if I have a system where inconsistent data is OK, I just let the normal cache expiration time logic handle that. Turning down expiration times to a few minutes, even 30 seconds, can still take lots of load off of particular "hot" objects that might be fetched multiple times quickly (such as from a series of AJAX requests) while making it unlikely that large inconsistencies will show up on the screen.

by zzzeek 15y ago

bjpless 15y ago

Your point is well taken; however, as the writer of the article, I'd say this. Our business requirements dictate that slightly inconsistent data is acceptable in certain circumstances. We would not retrieve objects through the caching flow in situations where absolute data integrity is required. That points makes all the difference, in my mind. To your point about excessive invalidation, that depends on your Read/Write workload.

zzzeek 15y ago
well if I have a system where inconsistent data is OK, I just let the normal cache expiration time logic handle that. Turning down expiration times to a few minutes, even 30 seconds, can still take lots of load off of particular "hot" objects that might be fetched multiple times quickly (such as from a series of AJAX requests) while making it unlikely that large inconsistencies will show up on the screen.