The way I'd solve this example is to create a unique constraint/index in the DB. The session check gives a quick pre-check, but in the event of a race the DB enforces absolute consistency.
If the constraint isn't possible or is too complex, then your "SELECT... FOR UPDATE" belongs on the check for whether someone is allowed to comment, not on the session. Select for update is a kind of locking, and the rule for locking is to do it as little as possible, in as isolated section of code as possible. So you do it around the code that checks if a user can create a comment and then creates it (which will probably be a small percent of your requests) vs. doing it in the session logic which gets run for 100% of requests (but is unneeded 99.99% of the time). On Sun, Feb 7, 2021 at 12:08 PM Matt <m...@satchamo.com> wrote: > The "post_comment" example of sessions appears to be incorrect: > https://docs.djangoproject.com/en/3.1/topics/http/sessions/#examples > > Imagine two HTTP requests coming in at the same time, both seeing that > "has_commented" is False, and then both create a comment and set the > session variable to True. > > I just experienced this issue myself, which is why I bring it up. > > I would offer to update the documentation...but I'm struggling to come up > with a way to actually make this pattern work with sessions! Assuming there > are other views that update other variables in the session, it seems like > you must lock the session when you read it (i.e. "SELECT...FOR UPDATE"). So > anything that reads or writes to the session must be wrapped in an atomic > block. > > I think it might be useful to add a method to support locking the session > before any reads/writes. Or maybe we should just update the docs to warn > people about how race prone sessions are? > > Any thoughts? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/89941f4b-61a2-446e-ba72-dfe428e0a9dbn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/89941f4b-61a2-446e-ba72-dfe428e0a9dbn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAD4ANxXYM6BPXLE0oq30w78BtxkV-ynoKBbObKyP7JORHO%2BJpQ%40mail.gmail.com.
