On Monday 18 March 2013 16:36:53 Aymeric Augustin wrote: > By default, the development server creates a new thread for each request it > handles. Not only does this negate the effect of persistent connections > (they're thread-local), > [...]
> 1) Do we want to enable persistent connections in production by default? > > 2) Assuming the answer to 1) is yes, can we fix runserver? > a) close connections at the end of the dev server request handler > => creates tight coupling between the dev server and the ORM :( > b) disable persistent connections when DEBUG = True > => badly targeted: some people may use runserver with DEBUG = > False, > or want persistent connections when DEBUG = True > c) ??? > If the persistent connections are thread-local, don't you want to close them anyway when the thread exits? > Florian independently discovered the same problem with gunicorn + gevent, > because the gevent worker runs each request in its own "thread" > (greenlet). ... but that fix will kill persistent connections under gunicorn. The solution that sounds "right" is to pool the persistent connections -- every thread that ends returns the connection to the pool. If I understand correctly, this would tie the ORM not to the dev server, but to the wsgi handler -- but in a sense where, actually, it should be tied. Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
