Stephen - you're right that a constraint is the best way to enforce
consistency in the DB. That doesn't fit every use case for sessions though
- people use Django's built-ins with many different kinds of data stores
that don't support locking or constraint semantics, such as remote API's.

Matt - I think we could remove that example.

As for a new session locking method, I'm not sure how feasible it is *in
general* since the session API is designed to back onto any kind of data
store. If you had an example implementation it would be good to see and
know how well it performs in a real world setting.

On Sun, 7 Feb 2021 at 18:58, Stephen J. Butler <stephen.but...@gmail.com>
wrote:

> 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
> <https://groups.google.com/d/msgid/django-developers/CAD4ANxXYM6BPXLE0oq30w78BtxkV-ynoKBbObKyP7JORHO%2BJpQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Adam

-- 
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/CAMyDDM2c7ZYU05qBKPGcms5vWj%3D0QXNV-_amdc1QvQL_%3DThMdQ%40mail.gmail.com.
  • Rac... Matt
    • ... Stephen J. Butler
      • ... 'Adam Johnson' via Django developers (Contributions to Django itself)
        • ... Matt
          • ... 'Adam Johnson' via Django developers (Contributions to Django itself)

Reply via email to