On Apr 24, 9:22 pm, Filipe Correia <[EMAIL PROTECTED]> wrote: > Hi, > > I think the following thread may help > you:http://groups.google.com/group/django-users/browse_frm/thread/22a6d00...
Except that no one has still yet explained why the page: http://www.djangoproject.com/documentation/modpython/ says to use prefork MPM and not to use the worker MPM. If there are valid reasons and you can describe specific problems that the worker MPM creates, please speak up. Otherwise, the page should really be changed by someone with the authority and standing to do it with the Django project developers, to reflect that there aren't any reasons why the worker MPM can't be used. :-( Personally I think that the myth that the worker MPM cannot be used has come up purely because people were using ancient versions of mod_python (ie., 3.1.X), or hit certain limitations in Django when using the worker MPM and thought it was the worker MPM rather than seeing it was an issue with Django that can also affect prefork MPM albeit maybe at a lessor rate of incidence. Some of the limitations that might have contributed to this belief are the fact that Django sessions don't use locking across the whole life of the session object as used by a request handler either within a process or across processes when there are multiple web server processes. This means that two separate request handlers wanting to use the same session object at the same time can interfere with each other and screw up data saved within the session database. An application making heavy use of AJAX techniques and the worker MPM might have a tendency to expose this problem more than when worker is being used. Next limitations is that Django has no way to restrict the session cookie to a specific path within a site. This means that if you are running two Django sites within the same virtual host under Apache, they can interfere with each other unless you set the SESSION_COOKIE_NAME value differently for each. The mod_python documentation doesn't mention this. Django really needs to add support for a SESSION_COOKIE_PATH value that can be used to set the path within a site the session cookie applies to. When using the WSGI adapter, it should also use SCRIPT_NAME properly and perhaps automatically use that as the SESSION_COOKIE_PATH. Another possible cause of problems is someone trying to run multiple Django instances within the one virtual host and not using the PythonInterpreter directive to force them to run in separate Python sub interpreters. This would be an issue because of the fact that Django uses global environment variables from os.environ to specify where the settings file is. This issue is only going to get worse when people using WSGI adapter think they can mount multiple Django instances within one host, especially when mod_python isn't being used and there is no means to separate them. I've also seen some speculation previously, but don't know the outcome, that caching by some database clients was causing problems under mod_python because different child processes were seeing slightly different views of data from the database. What was the final outcome on this issue? Thus, there are various issues with Django that might come up when using Apache and I reckon that someone problem hit them when using the worker MPM and perhaps wrongly thought it was the worker MPM causing the problems when it wasn't. If there truly was a problem with the worker MPM then there should also be problems with running Django on Windows as it works the same as the worker MPM except that there is only one child process and not multiple child processes like there can be on UNIX systems when using the worker MPM. 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 -~----------~----~----~----~------~----~------~--~---
