On Jun 27, 8:07 pm, Robert Coup <[EMAIL PROTECTED]> wrote: > Marty Alchin wrote: > > Regardless though, I think Jacob makes the best point so far: Django's > > cache system is robust enough to handle it if you pick a decent > > backend. And if there's a need to make the built-in options more > > robust, we can deal with that when the need arises. > > What about registering to watch for a signal given to the web server > process and invalidate the cache when that is received ? That way > someone who really wants to clear the dbsettings across multiple > processes can force it via a "kill -s" system script.
This wouldn't be a good idea if using Apache to host the application as Apache uses a lot of the signals for its own purposes and you would most likely interfere with its operation if you were to register a signal handler for a signal it uses. Because of the problems caused by applications registering signal handlers under Apache, mod_wsgi actually substitutes signal.signal() with a dummy function which logs a warning that signal registration is disabled for Python applications and otherwise ignores the request. See "Registration Of Signal Handlers" in: http://code.google.com/p/modwsgi/wiki/ApplicationIssues There has been some discussion in respect of WSGI applications registering signal handlers on the Python WEB-SIG of late and general consensus seems to be that no WSGI application should be relying on UNIX signals directly, only the underlying web server should be allowed to. This discussion was part of another discussion on somehow providing a form of event notification bus for applications. Feasibly, if a way was found of injecting an event into the process from outside, the bus being described could be a way of triggering the sort of action you are talking about in an application. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
