I would love to tackle this issue, since it is to my advantage, but really don't know where to start. Any ideas?
Seth On Mar 1, 10:59 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
