No, cannot really be done. This has been discussed a couple of times on the mod_wsgi list. One such discussion is at:
http://groups.google.com/group/modwsgi/browse_frm/thread/8ebd9aca9d317ac9 In general the same issues apply to all WSGI implementations. Graham 2009/4/14 Chimezie Ogbuji <ogbu...@ccf.org>: > Hello. I have a problem with a WSGI-based SPARQL server that I have been > unable to resolve for some time. I was told this is the best place to ask > :). I'm building a SPARQL [1] server that is deployed as WSGI/Paste > server. SPARQL queries are handled by the server and evaluated against a > MySQL database using mysql-python/MySQLdb to manage the connection. > > My goal is to be able to allow clients to close the connection in order to > kill queries that have been dispatched (in order to 'abort' them). > Unfortunately, when the client kills the connection, the application is not > signaled in any way. So, the result is that (for long-running queries), the > MySQL query continues to run even after the connection is closed (by > clicking cancel in the browser for instance). > > I would expect that when the connection is closed at the client side, this > should trigger a chain reaction of garbage collection (deletion of the > application object, and all the objects attributed to it including the DB > connection, etc.) that bottoms out in the db connection closing and MySQLdb > killing the query as a side effect of calling __del__ on the cursor and > database connection. However, this is not what is happening and it appears > that the once the result is served back to the client, the server and the > client are completely 'disconnected' for that particular request. > > Am I going about his the wrong way? Does WSGI simply not have anything to > say about such a situation ? If the problem isn't > WSGI, is there another WSGI implementation that is known to behave as > expected (i.e., closing the connection dispatches the deletion of the > objects involved in the request handling)? > > I was told to look into keep-alive, but the specification doesn't seem to > suggest that this would help me as it has more to do with re-using > connections for subsequent requests rather than specifying that the server > maintains a connection between the request and the objects involved in > handling the request at the server. > > Any help would be greatly appreciated. > > Thanks > > [1] http://www.w3.org/TR/rdf-sparql-query/ > > > =================================== > > P Please consider the environment before printing this e-mail > > Cleveland Clinic is ranked one of the top hospitals > in America by U.S. News & World Report (2008). > Visit us online at http://www.clevelandclinic.org for > a complete listing of our services, staff and > locations. > > > Confidentiality Note: This message is intended for use > only by the individual or entity to which it is addressed > and may contain information that is privileged, > confidential, and exempt from disclosure under applicable > law. If the reader of this message is not the intended > recipient or the employee or agent responsible for > delivering the message to the intended recipient, you are > hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If > you have received this communication in error, please > contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. Thank you. > > _______________________________________________ > Web-SIG mailing list > Web-SIG@python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com > _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com