Okay, maybe my text should have read "I've deployed Django with Apache and ModPython where each request *may* be serviced by a separate process."
Concurrent requests being handled within the same interpreter was my concern with Django. After a quick look at the source code it seems that DatabaseWrapper is thread aware. Hopefully it'll cope with sqlite3's threadsafety level which means you cannot share a connection object among multiple threads. You're right in that there isn't any threading support with sessions. Writing session information back to the database is atomic though so the worst you'll get is data being overwritten by the last altered session. As you say, that's one to watch out for with concurrent Ajax operations which alter session information. Wouldn't this still be an issue with the non-threading model? The only way to ensure session integrity in these corner cases would be to lock on the session id during a request (somehow - probably not trivial). That would mean that requests from the same source would be processed sequentially and not in parallel. It's probably easier just to be very careful with parallel requests. Justin > On Aug 29, 1:39 am, Justin Johnson <[EMAIL PROTECTED]> wrote: > >> I've managed to get Django working nicely with CherryPy using WSGI. >> Previously I've deployed Django with Apache and ModPython where each >> requested is serviced by a separate Python instance. >> > > How you think mod_python works is wrong, or at least the way you > explain it is deceiving in its meaning. > > In mod_python, each request is not 'serviced by a separate Python > instance'. > > In the case of prefork MPM in Apache, although it isn't threaded and > so concurrent requests can't be handled at the same time within a > single interpreter instance, successive requests do get handled in the > same Python interpreter instance. In other words, the interpreter is > not thrown away and instead persists until the process itself is > killed, which may only be when Apache itself is shutdown or restarted. > > In the case of worker MPM in Apache, multithreading is used and so > concurrent requests do get handled in the same interpreter at the same > time. Again, the interpreter persists for the life of the process. > > Where confusion often arises and why this myth that a separate Python > instance is used for each request persists is that Apache on UNIX is a > multi process web server. Thus your requests aren't necessarily all > handled in the same process, instead they can be distributed across > multiple processes. The use of multiple processes by Apache and the > fact that it can create more on demand as load rises, means that > Apache is much better able to scale than solutions which use a single > Python process with web server implemented in Python only. > > I really wish this myth about mod_python would die. :-( > > For a bit more information about the process/interpreter model in > mod_python read: > > http://www.dscpl.com.au/wiki/ModPython/Articles/TheProcessInterpreterModel > > >> This isn't the case with CherryPy though as it's thread based which >> leads me to the following concern: is it safe to serve Django with >> CherryPy? >> > > If one takes the warning in mod_python documentation that only prefork > MPM for Apache should be used and worker MPM should not, then it would > follow that using the CherryPy multithreaded web server would not be > safe. Similarly, it wouldn't be safe to run Django on Windows with > Apache either. > > In practice, discussions in the past have indicated that there are no > known multithreading problems in Django itself. Thus the warnings > about avoiding worker MPM and thus multithreaded MPMs may not be > strictly applicable. Now although Django may be safe for > multithreading, you would still need to ensure that your higher level > code implemented in Django is multithread safe. You would also need to > ensure that you are using recent versions of any database adapters and > that they declare themselves as multithread safe. > > Most importantly, you should rigorously test your application to > ensure that it is truly safe to use in a multithreaded web server. > Areas which I would suggest you look at closely are use of session > objects as these from memory do not provide a locking mechanism, and > so in an AJAX heavy application which issues lots of concurrent > requests and each handler for them wants to manipulate the same > session object, you might run into problems with the handlers and > sequencing of operations against the session object. > > 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 -~----------~----~----~----~------~----~------~--~---
