Concurrency control in Django model

I don't think that 'keeping a version number or timestamp' works.

When self.version == self.read_current_version() is True, there is still a chance that the version number got modified by other sessions just before you call super().save().

I agree with the introductory explanation from Joe Holloway.

I want to contribute with a working snippet relative to the very last part of his answer ("In terms of Django, optimistic concurrency control can be implemented by overriding the save method on your model class...")

You can use the following class as an ancestor for your own model.

If you are inside a database transaction (for example, by using transaction.atomic in an outer scope), the following Python statements are safe and consistent

In practice via one single shot, the statements filter + update provide a sort of test_and_set on the record: they verify the version and acquire an implicitly database-level lock on the row.

So the following "save" is able to update fields of the record sure it is the only session which operates on that model instance.

The final commit (for example executed automatically by _exit_ in transaction.atomic) releases the implicit database-level lock on the row:

class ConcurrentModel(models.Model):
    _change = models.IntegerField(default=0)

    class Meta:
        abstract = True

    def save(self, *args, **kwargs):
        cls = self.__class__
        if self.pk:
            rows = cls.objects.filter(
                pk=self.pk, _change=self._change).update(
                _change=self._change + 1)
            if not rows:
                raise ConcurrentModificationError(cls.__name__, self.pk)
            self._change += 1
        super(ConcurrentModel, self).save(*args, **kwargs)

It is taken from https://bitbucket.org/depaolim/optlock/src/ced097dc35d3b190eb2ae19853c2348740bc7632/optimistic_lock/models.py?at=default

The short answer, this really isn't a Django question as presented.

Concurrency control is often presented as a technical question, but is in many ways a question of functional requirements. How do you want/need your application to work? Until we know that, it will be difficult to give any Django-specific advice.

But, I feel like rambling, so here goes...

There are two questions that I tend to ask myself when confronted with the need for concurrency control:

• How likely is it that two users will need to concurrently modify the same record?
• What is the impact to the user if his/her modifications to a record are lost?

If the likelihood of collisions is relatively high, or the impact of losing a modification is severe, then you may be looking at some form of pessimistic locking. In a pessimistic scheme, each user must acquire a logical lock prior to opening the record for modification.

Pessimistic locking comes with much complexity. You must synchronize access to the locks, consider fault tolerance, lock expiration, can locks be overridden by super users, can users see who has the lock, so on and so on.

In Django, this could be implemented with a separate Lock model or some kind of 'lock user' foreign key on the locked record. Using a lock table gives you a bit more flexibility in terms of storing when the lock was acquired, user, notes, etc. If you need a generic lock table that can be used to lock any kind of record, then take a look at the django.contrib.contenttypes framework, but quickly this can devolve into abstraction astronaut syndrome.

If collisions are unlikely or lost modifications are trivially recreated, then you can functionally get away with optimistic concurrency techniques. This technique is simple and easier to implement. Essentially, you just keep track of a version number or modification time stamp and reject any modifications that you detect as out of whack.

From a functional design standpoint, you only have to consider how these concurrent modification errors are presented to your users.

In terms of Django, optimistic concurrency control can be implemented by overriding the save method on your model class...

def save(self, *args, **kwargs):
    if self.version != self.read_current_version():
        raise ConcurrentModificationError('Ooops!!!!')
    super(MyModel, self).save(*args, **kwargs)

And, of course, for either of these concurrency mechanisms to be robust, you have to consider transactional control. Neither of these models are fully workable if you can't guarantee ACID properties of your transactions.