Opened 9 years ago

Closed 8 years ago

Last modified 5 years ago

#6641 closed Uncategorized (fixed)

Concurrency issue with get_or_create

Reported by: JEFFGUINNESS Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords: get_or_create
Cc: tomasz.zielinski@…, gerdemb Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


This is from Travis Terry post on and where he is much more eloquent then I am, I will post his some of his comments.

Two threads/processes/servers (let's call them P1 and P2) need to
concurrently create a unique object

  1. P1 calls get_or_create(), which tries to get the item (it doesn't exist)
  2. P2 calls get_or_create(), which tries to get the same item (it doesn't exist)
  3. P1's get_or_create() tries to create the item (this works and returns the item)
  4. P2's get_or_create() tries to create the item. One of two things happens:
    1. a second item is created with the same parameters if this doesn't violate a UNIQUE constraint
    2. the second create fails (because of a UNIQUE constraint) and raises an exception

The following pseudo-code handles the problem:

def get_or_create(**kwargs):
       obj = get(**kwargs)
          obj = create(**kwargs)
          obj = get(**kwargs)
    return obj 

Attachments (2)

query.diff (1.0 KB) - added by JEFFGUINNESS 9 years ago.
Diff file
6641-get_or_create.diff (1.2 KB) - added by Timothée Peignier <tim@…> 9 years ago.
Catch IntegrityError

Download all attachments as: .zip

Change History (11)

Changed 9 years ago by JEFFGUINNESS

Diff file

comment:1 Changed 9 years ago by ubernostrum

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

This really doesn't feel like it warrants inclusion in Django's core, since a site which has traffic patterns that would generate this problem can easily use something like Marty's suggestion in the mailing-list thread.

comment:2 Changed 9 years ago by mtredinnick

  • Patch needs improvement set
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Triage Stage changed from Unreviewed to Accepted

This patch isn't too intrusive and I can't imagine how it will fail incorrectly. Plus it doesn't add a lot of overhead. So, sorry James... I realise it's borderline, but I think it might be worth it.

Patch needs improvement, though. Catching Exception is wrong. You're looking for IntegrityError, so catch it. That's one of the exceptions we carefully promote into django.db.backends so it's portable.

Changed 9 years ago by Timothée Peignier <tim@…>

comment:3 Changed 8 years ago by PhiR

  • Patch needs improvement unset
  • Triage Stage changed from Accepted to Ready for checkin

Marking as ready since the new patch addresses malcom's comments.

comment:4 Changed 8 years ago by PhiR

  • Version changed from 0.96 to SVN

Changing the version, the patch applies to SVN (and qsrf by the look of it, the issue is still present there).

comment:5 Changed 8 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [7289]) Fixed #6641 -- If we lose a race when creating a new object in get_or_create,
re-get the result from the database and return that. Thanks, Jeff Guinness and
Timothée Peignier.

comment:6 Changed 5 years ago by TomaszZielinski

  • Easy pickings unset
  • Severity set to Normal
  • Type set to Uncategorized

comment:7 Changed 5 years ago by TomaszZielinski

  • Cc tomasz.zielinski@… added

comment:8 Changed 5 years ago by legutierr

comment:9 Changed 5 years ago by gerdemb

  • Cc gerdemb added
  • UI/UX unset
Note: See TracTickets for help on using tickets.
Back to Top