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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
