It sounds like we need a way to tell the worker that we are done sending requests to it so that the worker can do cleanup (of which db conn close is one task). This mirrors the previous request_finished "coupling" to requests_finished.
(OS?) Signal? Sentinel queue/socket/named pipe + background thread? On Mar 18, 2013, at 7:36 AM, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > On 28 févr. 2013, at 00:12, Aymeric Augustin > <aymeric.augus...@polytechnique.org> wrote: > >> I'm just wondering if 10 minutes is a good default value for CONN_MAX_AGE. > > > Since I committed the patch, I discovered that persistent connections don't > interact well with runserver. > > 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), but it also keeps connections open until they're > garbage collected, making it easy to exceed the maximum number of available > connections. > > Florian independently discovered the same problem with gunicorn + gevent, > because the gevent worker runs each request in its own "thread" (greenlet). > > > This raises the following questions: > > 1) Do we want to enable persistent connections in production by default? > a) yes > b) yes, through a deprecation path > c) no > > 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) ??? > > > The lazy solution is to disable persistent connections by default, document > the problem with servers that run each request in its own thread, and > recommend to set `DATABASES['default']['CONN_MAX_AGE'] = 0 if settings.DEBUG > else 600`. > > Besides, I've observed that performance is often less of a concern that > backwards-compatibility and ease of use; from this perspective, disabling > persistent connections would be appropriate. > > > What do you think? > > -- > Aymeric. > > > > -- > 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. > > -- 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.
