[Django]-What is the simplest way to lock an object in Django

select_for_update is the simplest way to acquire a lock on an object, provided your database supports it. PostgreSQL, Oracle, and MySQL, at least, support it, according to the Django docs.

Example code:

import time

from django.contrib.auth import get_user_model
from django.db import transaction


User = get_user_model()


@transaction.atomic
def my_example_function():
    my_user = User.objects.all()[0]

    print("Acquiring lock...")
    locked_user = User.objects.select_for_update().get(pk=my_user.pk)
    print(locked_user)

    while True:
        print("sleeping {}".format(time.time()))
        print("holding lock on {}".format(locked_user))
        time.sleep(5)

Note that you have to use select_for_update within a transaction, hence the @transaction.atomic decorator.

Since your scope is limited to deletes, and not also updates, one option would be to rethink the idea of a “delete” as an “unpublish” action. For instance, take the following model:

class MyManager(models.Manager):
    def get_query_set(self):
        super(MyManager, self).get_query_set().filter(published=True)

class MyModel(models.Model):
    objects = MyManager()
    published = models.BooleanField(default=True)
    ... your fields ...

    def my_delete(self):
        self.published = False
        super(MyModel, self).save()

    def save(self):
        self.published = True
        super(MyModel, self).save()

In this way, whenever an edit is committed, it is visible to all users… but others are still free to delete items. One advantage of this technique is you don’t have to have any extra logic to lock items and present a different UI to the user. Disadvantages are extra space used in the db table, and the rare circumstances where a deleted item “magically” reappears.

(This is probably just a starting point. If you took this path, you’d likely want to do a variation on this idea depending on your use case.)

I’d suggest a simple read-write lock, as you don’t want to block users from accessing the object concurrently (only from editing).

A general approach to doing this would be to create a function that maintains a count of active readers. When you need to write to that object, you would create another function that would prevent new readers from getting access (think a maintenance page), and possibly redirect existing readers away. Once there are no more readers left, you would complete your write, then unlock the object.

First you need to know that there are two locking mechanisms: optimistic and pessimistic locking. How they differ is explained here. As far as I know there is no package implementing pessimistic locking for Django. For optimistic locking the most feature complete library is django-concurrency.

In the accepted answer, there can still be race conditions between checking obj.locked and setting it to true. This can be fixed by using a separate model.

There is also the potential for deadlocks (if the object is never saved). This can be fixed by using a context manager.

So I believe this version has some benefits:

class SomeModel(models.Model):
    @contextlib.contextmanager
    def lock(self):
        # raises IntegrityError if already locked
        lock = SomeLock.objects.create(obj=self)
        try:
            yield
        finally:
            lock.delete()

class SomeLock(models.Model):
    obj = models.ForeignKey(SomeModel, on_delete=models.CASCADE, unique=true)