Monday, September 5, 2005

It looks like the problem is solved. Django creates one (1) connection to database and reuses it to handle requests. Multithreaded FastCGI creates threads to handle requests. These threads make requests to MySQL, which gets confused and loses its cool^H^Honnection. This process is random and compounded with multiple web requests at the same time. For example, if Google Web Accelerator decided to prefetch some pages, your web site would be hosed.

Luckily, the only place, which needs fixing, is one small class: mysql.DatabaseWrapper.

I added a dictionary of connections so every thread will have it's own connection. Apparently it solved the problem. Additionally I ping connection to make sure it is not timed-out, and do some simple clean up, when threads are finished.

PostgreSQL doesn't have this problem. For those of you keeping score at home, MySQL loses a cookie point.

I decided to try how well Opera works with my site. It mostly works. You can go and see stuff but all Dojo-related code doesn't work. Interesting that Google Maps works properly.

When I switched to admin mode to edit this article, it turned out that TinyMCE doesn't work either.

But good news is Dojo and TinyMCE failed gracefully.

I complained about instability of this site in my previous post. Now, after intensive googling, it looks like it may be related to multiple threads or forked processes using the same connection to MySQL. Apparently it can confuse MySQL. Children should create their own connections after spawning.

If Django does reuse connections, it may be possible to fix it. Otherwise, CGI is the way to go. The latter solution would be slow.