#8616: Session file corrupted with SESSION_SAVE_EVERY_REQUEST = True
----------------------------------------------+-----------------------------
Reporter: [EMAIL PROTECTED] | Owner: nobody
Status: new | Milestone: 1.0
Component: django.contrib.sessions | Version: SVN
Resolution: | Keywords: session, file,
race
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
----------------------------------------------+-----------------------------
Comment (by [EMAIL PROTECTED]):
*Previous post changed to use wiki formatting*
The problem (I think) I am seeing is this:
1. Request A opens the file for reading, reads the session data, and
closes the file.
1. Request A opens the session file for writing, truncating the file.
1. Request A starts to write the session data to the file.
1. Request B opens the file for reading, reads the partial data from the
file, and closes the file.
1. Request A finishes writing the session data to the file.
1. Request B attempts to decode the partial session data and fails.
1. Request B creates a new empty session.
1. Code executed by Request B and subsequent requests fails because of
missing session data.
I encountered this problem before the recent session changes, so the chain
of events above may be incorrect. The core of the issue is (I think) that
while the session data is being written to the file, other requests may
read the file before the write is complete.
This seems to manifest itself only when all of these conditions exist:
- SESSION_SAVE_EVERY_REQUEST = True causes the session data to be written
on every request.
- Django is not running under the development server so the requests are
not serialized.
- Multiple requests from the same session arrive very close together (as
can happen with AJAX requests).
Before the recent session changes, I had tried using the
django.core.files.locks module to lock the file appropriately (shared for
read, exclusive for write) immediately after the file was opened, but I
still got failures (not sure why). It was only when I used the locking
flags to os.open() that the problem went away. Unfortunately, the
O_SHLOCK and O_EXLOCK flags seem to be BSD specific, so while they are
available on my Mac, they may not be under other flavors of *nix. I
looked at Python 2.5.1 running on RHEL 4 and they were not there. More
recent version of Linux may or may not have them.
It is possible that other factors, that may have been fixed by the recent
session changes, caused the failures when I tried the django file locking
before. I'll give it another go.
--
Ticket URL: <http://code.djangoproject.com/ticket/8616#comment:4>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
