On Thu, 2007-03-01 at 20:17 -0800, Graham Dumpleton wrote:
[...]
I wrote:
> > > I'm wondering if this may lead to race conditions along the lines of:
> >
> > >         thread A creates a session
> >
> > >                         thread B creates a session
> >
> > >         thread A stores "foo = 6" in session
> >
> > >                         thread B stores "blah = 1" in its session
> >
> > >         thread A stores session (which contains foo=6)
> >
> > >                         thread B stores session (which does NOT have 
> > > foo=6)
> >
> > > might be happening if you are doing lots of partial updates.
> 
> This doesn't make sense. 

Actually it makes a lot of sense now that I look at the code.

> Normally the way sessions work, a second
> request is usually locked out until the first request has finished
> with the session object and released it. Thus there can be no
> overlapping changes unless you are doing silly things like unlocking/
> locking them yourself during a request. At least this is how
> mod_python sessions work. How Django sessions (which don't actually
> use mod_python sessions) work I don't know.

Just to keep things on the right track for debugging Set's problem, I'll
note that this isn't correct for Django sessions. As can be seen from
the code in django/contrib/sessions/middleware.py and models.py, we
don't do any cross-thread or cross-process locking when creating a
session instance. Maybe we well should be doing something like that for
people who want to do simultaneous updates -- as might happen in an AJAX
driven site -- but, right now, we do not.

A lot of Django enhancements like this are historically driven by usage
patterns: the whole framework was written for one -- fairly broad --
purpose and is gradually and carefully extended to handle other
reasonable uses as they come up. This would be a good mini-project for
somebody to look at doing if they felt so inclined. A bit of design work
would be required, not just a one-line patch, I supsect, but it's not
going to be of the "cure cancer" level of difficulty.

Regards,
Malcolm


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to