On Thu, Dec 20, 2012 at 5:42 AM, Wade Williams <[email protected]>wrote:
> Hi all. > > I've got a custom session middlware built that is simply extending the > session base. The only interesting thing this backend is doing is using a > different session table than django's stock one -- this is for integration > with a pre-existing PHP site we are in the process of migrating away from. > > Everything is working fine, except, I decided to try and truncate the > sessions table in order to test something -- to my surprise, I couldn't > load the site after that -- it just hung indefinitely. > > If I delete my session cookie, the site loads up no problem. > > I'm running django 1.5a1 as we aren't scheduled for a public launch on > our django code until April. Is this a 1.5 bug? Or is there something > messed up with my session middleware? > > When I try and trace where the error could be coming from, I wind up > opening up the django codebase -- I don't believe there are any bugs in my > middleware (especially considering it works great until you do something > like truncate the sessions table). > > PS I did try deleting the session table completely and re-running > manage.py syncdb just incase there was some sort of relationship problem, > but that doesn't appear to be the case. > > Any suggestions much apprecaited. > I can't say I've noticed any session table-related issues recently, and although it's possible I might have missed something go past, I haven't noticed any big changes to the session middleware either -- certainly nothing that sends up a red flag for the behaviour you describe. So - unfortunately, I can't really offer any advice here. If I were to try and debug the problem, I'd start looking into the cause of the lock. Where is the hang occurring? Is it a database-level lock trying to retrieve a row (possibly locking on a transaction?) Is the session backend looping on something? There's a loop to allocate a new session key -- if this is going into an infinite spin, it would appear as a lock. Alternatively, an operation in this loop might just be running *really* slowly; *technically*, the lock would eventually be released, it's just going to take a few minutes. Beyond that, there's not much we can do without seeing code. You're reporting this as a problem with a custom session backend, so your first job is to prove that it isn't your own code that is the problem. If you can demonstrate the same problem with a native Django session backend, it would definitely be a release-blocking issue. If you can demonstrate that your session backend that was functional on Django 1.4 is now having problems with 1.5, then we might also have a regression that would be a release blocker -- however, it depends on the exact nature of the regression. 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.
