Response middleware can leak db connection

[Maniac <Maniac@…>]

Both modpython.py and wsgi.py do this:

    try:
        request = ModPythonRequest(req)
        response = self.get_response(req.uri, request)
    finally:
        db.db.close()

    # Apply response middleware
    for middleware_method in self._response_middleware:
        response = middleware_method(request, response)

... meaning that if any response middleware uses db connection it will not be closed. The most common middleware doing it is Session.

The right thing to do would be stick the middleware part up under try block.

However even more right thing (I think) would be to refactor both request and response middleware application along with finally: part into BaseHandler._get_response to avoid maintaining identical code in modpython.py and wsgi.py.

[hugo]

yep, I wrote myself a response middleware that just closes the current db connection to make sure that connections are allways closed, regardless of any problems. The leaked connections can pose problems, as they are "idle in transaction" under PostgreSQL and therefore might block records they read in the transaction (psycopg does an implicit transaction that is only closed on db.close() or one of .save() or .delete() in Django) due to the multi-version-nature of PostgreSQL.

[junzhang.jn@…]

this is fixed at rev:2358

[Adrian Holovaty]

(In [2474]) magic-removal: Fixed #1445 -- Moved response middleware-handling code inside try/finally that closes DB connection

[Maniac <Maniac@…>]

That was fast :-). Thanks!

[bryan@…]

This needs to be applied to trunk as well. I'm running a django server using trunk and the postgres idle connections keep piling up. After applying this fix to trunk, the idle connections don't appear.

[Adrian Holovaty]

Closing this because trunk is magic-removal.