Re: Truncating Session Table makes site hang indefinitely

On Thu, Dec 20, 2012 at 5:42 AM, Wade Williams <wwilliams@local-motors.com> 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 django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.