El jueves, 2 de junio de 2016, 11:48:33 (UTC-3), Florian Apolloner escribió: > > > No it would not be great at all, connections could theoretically shared > between threads etc… In general Django has no way of knowing when you want > to close it. In the end a "dying" thread* which is not properly closed is > a bug in your code anyways.* > > Cheers, > Florian > >
Not always, for example, on amazon elastic beasntalk when you either restart the app server or upload a new version, it basically kills apache and all WSGI processes through a sigterm, so those thread pools are probably killed in a bad way and you don't really have control over that. Also you don't really have control on the life of a thread pool thread, so a given thread could be gracefully stopped by the pool implementation but you can't really do any cleanup code before it happens for that thread (at least not that I'm aware of for multiprocessing.pool.ThreadPool) As ayneric pointed out, it seems like those connections are correctly closed most of the time when a thread dies, but for some reason, postgres would keep some connections opened. Are there any rare cases where even if the thread is stopped the connection won't be closed? The only thing I can think of are that those threads are never garbage collected or something. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/797440be-cc41-44ac-b382-10dd5ea2cb5b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
