On Thu, Dec 20, 2012 at 9:25 AM, Wade Williams <[email protected]>wrote:
> Thanks Russ. I too thought it might be the loop to allocate a new session > key, but after studying the code and trying some forced debugs (print x) I > thought it could be due to the super __init__ spinning when it couldnt find > the session key in the db. I can access and insert into the DB table during > the lock, and the lock never seems to end (I've run it for atleast an hour > with no stop). We've built out our stuff exclusively on 1.5 so shouldnt be > any 1.4 migration issues. Here is the session middleware: > > To be clear - it's wasn't so much migration issues I was worried about -- it was whether we've introduced a regression into Django core. Your original question was "is this a 1.5 bug?", which suggested to me that you've seen your code work on older version of Django. If that's not the case, then it seems that you're reporting "my custom session middleware doesn't work". While this is certainly a problem (for you), it's no longer pointing at a fundamental problem in Django itself that needs to be addressed before we cut a release candidate for 1.5. As for the lock itself -- you've pointed at a number of places where the lock *isnt'*, but you haven't pointed at where the lock *is*. Is it a database lock, or a processing loop lock? Is it on retrieving the session, or creating a session? Which line of code is locking? You've said you've done some print debugging -- what lines are (and aren't) executed? Ultimately, you're going to need to investigate this yourself -- I (and others) can give you hints of places to look, and seeing the code will help us, but you're the one with the live test case. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" 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-users?hl=en.
