[Django]-Django caching for web applications

1👍

There are some issues when using memcached for invalidating/updating stale data due to race conditions, which one of the main Johnny Cache backends relies on. In your particular case, say you have 10 updates in total and then two different users in two separate processes create a ticket update. It’s quite possible that you end up displaying only 11 updates to both, even though there are 12 in total: one of them is going to end up with a serious case of WTF?

That’s the kind of problem you’re going to have with any model/queryset invalidation solution if memcached is your store. Your not joining a lot of rows from several different tables, so this shouldn’t be considered as an expensive query–you could probably just rely on the database.

But not understanding the full extent of the work your doing, it would be improper for me to suggest such a thing. What I would suggest, though, is that you take a look at the possibilities of using mongoDB, Tokyo Cabinet or Redis as a cache replacement for memcached, in situations where you need to have fine-grained control over updating critical user data.

Another thing you can do is to have all requests that update such data routed through an instance of your application that runs in a single process exclusively. This would completely alleviate any update contention on memcached and it’s viable for applications where reads greatly outperform writes, although I can see how this can quickly become a maintenance nightmare for developers.

0👍

Not quite what you are after, but johnny-cache will cache querysets, automatically invalidating on writes.

It may do enough of what you are after: and it is no work to use after setting up.

Leave a comment