views:

106

answers:

2

I have a model MyModel that has a field expiration_datetime.

Every time a user retrieves an instance of MyModel I need to first check if it has expired or not. If it has expired, than I need to increment some counter, update others, and then extend the expiration_datetime to some time in the future.

So the view would do something like:

if object.expiration_datetime < datetime.datetime.now(): 
    object.counter = F('counter') + 1 
    object.expiration_datetime = F('expiration_datetime') + datetime.timedelta(days=1) 
    object.save() 

There's a race condition in the code above. Say thread 1 checks and finds that the current instance has expired, it proceeds to increment the counter and extend the expiration datetime. But before it could do so, thread 2 is scheduled and does the same. By the time thread 1 finally finishes, counter has been incremented twice and expration_datetime has been extended twice.

This looks like it should be a pretty common issue. What is the most efficient way to handle it? Ideally I'd like to be able to handle it within Django in a database-portable way.

+1  A: 

This may be a good use case for optimistic locking. There's a few ways to do it:

  • You can have a version number, and you run your UPDATE queries so that it always includes the version number in the WHERE clause, and then check if any rows were changed.
  • Include every value of the record (before the changes you made) in the WHERE clause, that way you can be sure that the record you are saving is exactly the same as when you read it.

How to implement optimistic locking in Django? Check out this question: Django: How can I protect against concurrent modification of data base entries.

wuputah
+1  A: 

Use a database transaction. They're designed to handle cases exactly like this.

If you're using MySQL, be aware that only InnoDB tables support ACID transactions, so make sure your tables use the InnoDB engine.

Nathan Davis
Yup. I can't speak for MySQL, but the default with SQLite is basically “once data has been read on a transaction, other readers will block until the transaction has finished”. So once you've got `obj.expiration_datetime`, you'd be guaranteed that no one else could read it.
David Wolever
To clarify, in MySQL, you have to read the data using a [`SELECT ... FOR UPDATE` query](http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html), a form of (pessimistic) row locking. It does not have [support in Django](http://code.djangoproject.com/ticket/2705) at this time, so database agnosticism would be difficult.
wuputah
Why do you say you *have* to do a SELECT ... FOR UPDATE first? I couldn't find anything in the MySQL documentation that suggests that.
Nathan Davis
Because reading data inside a transaction does not lock the data; it only establishes that the data is a consistent snapshot of the database (i.e., that snapshot will not affected by outside transactions). Other transactions can still read and update the data while that transaction is running. The MySQL docs explain the scenario pretty well: http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html
wuputah