How to run Django on Windows and cope with Apache not having a daemon mode?

Question

Evolution of this question

This started as an attempt to find other recommendations for running Django on Linux, accessing SQL Server via Django-PyODBC, and supporting Unicode as competently as in installations running Django on Windows.

After failing to materialize with a good solution for ODBC drivers in Linux that would provide the same level of support for Unicode as the Windows ODBC driver; the question morphed into coping with the negative side-effect of not having an Apache daemon mode in Windows.

The question

If you run Apache+mod_wsgi on Windows, every time you deploy new Django code you are required to restart the Apache server. See Graham's answer for details on why.

How to run a dependable set of applications and services when you might be required to restart Apache, denying service until it completely restarts?

The issue

We use SQL Server 2005 and we need to support unicode characters and certain characters (like smart-quotes) generated in Microsoft Office applications.

Running Django atop SQL Server 2005 requires us to use Django-PyODBC. It works great on Windows/Linux/Mac OS X; but if you require unicode support, you are out of luck on Linux / Mac OS X - the ODBC drivers for SQL Server in Unix are in varied stage of unicode compliance. FreeTDS, the open source driver, works for some characters if you specify a client character encoding of UTF-8 (*); but doesn't support all characters.

In our tests, running Django on Windows 2003 and using the Microsoft ODBC driver allowed us to properly insert/update/select any character in several different languages, and the Microsoft smart characters from Office applications.

But running on Windows means that every time we deploy new code we are required to bounce Apache - which means a few seconds without service.

---

(*) The only way we managed to get to the point where some characters would be accepted with FreeTDS, frankly, was to add a client charset entry to freetds.conf:

[a_db_server]
    host = a_db_server
    port = 1433
    tds version = 8.0
    client charset  = UTF-8

Answer 1

In relation to reloading on Windows when using Apache/mod_wsgi, read my response to:

http://stackoverflow.com/questions/1685185/server-software-choice-for-django-live-staging/1685300#1685300

Answer 2

Might be bad form to accept one's own answer, but it suited our case and it may help others...

---

First and foremost: we gave up trying to find an ODBC driver that would work properly with PyODBC and support unicode as competently as the Microsoft native ODBC driver. FreeTDS works partially, and some of the commercial drivers out there just didn't cut it in our tests. We considered a ODBC-JDBC bridge, but never really tested it.

We also thought about using an ODBC router, but given the price for a multi-user solution, the potential for more complexity, and the low load scenario for our Django apps; we decided to just stick with running Django on Windows and try to cope with the requirement of restarting the Apache server every time a new version of any of the Django apps is deployed.

What we did to cope with the Apache restart and still provide service availability:

• We deployed an Apache server as a proxy/load-balancer to a cluster of (at the moment) two Apache servers running on Windows
• On each of the Windows Apache servers in the cluster we have all our Django apps running
• When new code must be deployed to the servers we:
  • Disable one of the servers in the cluster via Apache's balancer-manager interface
  • Apply the updates and install any new Django apps in the disabled server
  • Test the modifications in the disabled server
  • Reenable the the server in the cluster via Apache's balancer-manager interface
  • Perform the same steps for the second server

As long as one of the servers in the cluster is enabled and running, the applications and services are available to our users - no interruption. At the same time we gained some load-balancing (in our case we really don't need it at this point).

The proxy Apache servers rewrites all the redirects and cookie response headers, so as long as people are accessing the services through the proxy, there are no modifications needed in the Django code whatsoever.