Indeed, locking is hard. I think it'd be better to warn more about how
sessions do not have guarantees against parallel writes. And perhaps we
could update the example to use the session as a cheap first check whether
the user has commented, actually defending with a full query against the
database
Thinking out loud: You can't just lock the session when you think you have
a critical section of code in a view because the session data is stored in
one field in the database, and is *completely overwritten* on write.
Consider this case:
Thread A: Read session data
Thread B: Open transaction,
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
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
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 Tr
