On Tue, Jan 11, 2011 at 9:00 PM, Kenneth Gonsalves <law...@thenilgiris.com> wrote: > I do not think it does - django is not a webserver or server like zope > for example. So what does 'stays up' mean?
it is. depending on how you deploy, it's a FastCGI server, or a WSGI server. in any case, the process is started once, lots of initializations are done, and it starts receiving user's requests (after some translations from the frontend web server). If you modify non-local resources in memory, they are available for the next request. Of course, most schemas start more than one process or thread, and you never know which one will service the next request, so you can't rely on that being available. Still, it's the base of the 'memory' cache backend: simply a global Python variable that holds data from previous requests. Another complication is that usually there's a request counter, and after it goes to zero, the thread/process is killed and another one is started. That's usually done to limit any memory leak or similar degradation, but it's done after several (sometimes hundreds of) requests, not for each and every one like on PHP. Why is that important? because all the models and urls and similar scaffolding are done once and used afterwards. If you do funny things there and/or don't take in account the lazy nature of Querysets, you might see some strange things happening. At the same time, it means Django is free of the "the most classes you initialize, the slower your app is" effect in PHP. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
