On Mar 2, 2:57 pm, "Seth Buntin" <[EMAIL PROTECTED]> wrote: > That probably isn't too far off. One time it did work and it was > weird so I might have actually got one of the threads to fire > correctly. Is there a way to limit the amount of threadsmod_python > uses?
The threads are not created by mod_python, they are created by Apache. For each client request Apache will handle it in a separate thread taken from a pool of threads. If the response for a request needs to come from an application running under mod_python, then the call through to mod_python/Python simply uses the existing thread that Apache created. The only way to limit the number of threads is by changing the configuration of Apache, but on Windows this would be a silly thing to do as there is only one Apache process and if you limit your threads to 1 to avoid perceived threading issues, all client requests will then effectively be serialised which would impact performance and would screw badly with AJAX applications that may want to have multiple concurrent requests going at the same time. > > 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. 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. If there is some problem with locking and concurrent requests changing the same actual session object at the same time it should be easy to pick up by adding into your code suitable debug logging at start/end points related to manipulation of session object and possibly in between, which shows identity of request/thread doing the manipulation. Graham --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
