Home/ Questions/Q 3976198
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T04:46:34+00:00

My question is about best practices for caching database updates in Django. I’m writing

  • 0

My question is about best practices for caching database updates in Django.

I’m writing a ticketing system. I have a Ticket model and an Update model. Each time a user adds an update to a ticket, an Update is created and linked as foreign key to the Ticket.

I have a TicketDetail view, that shows the Ticket description and the associated Updates. Users can add an Update from this view. I’ve enabled site-wide caching with memcached.

If a user adds an update and then reload this view, they won’t see the update for a while. I get why, because I need to enable per-view caching, and turn it off for this view.

But to enjoy the full speed of caching, what I’d really like to be able to do is enable caching for this view, but invalidate the cache as soon as a user makes an update.

Is there a straightforward way to do this? Thanks much!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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