Yes, mainly some things that needs to be done async and you don't want to keep up the request for those such as email sending or logging. So this work is just offloaded to a thread pool and the request returns instantly. Also when you are using auto scaling services from amazon and since each thread pool is started per server process, it means your pools can also automatically scale, you don't really want to get into all the issues of configuring celery and messages queues and such just for this.
El miércoles, 1 de junio de 2016, 23:19:29 (UTC-3), Stephen Butler escribió: > > Is there a good reason to do this with your own custom thread pool > management inside Django and (I'm assuming) WSGI? Celery is a well > understood solution to the problem of background tasks and has a really > nice API. > > On Wed, Jun 1, 2016 at 5:34 PM, Cristiano Coelho <[email protected] > <javascript:>> wrote: > >> Let me start saying sorry if this actually belongs to django-users rather >> than developers. >> >> I'm curious about (and if someone can point me to the code) how exactly >> django handles database connections (in particular when persistent >> connections are used). As I can tell from the docs, they are kept by thread >> and opened and closed (or returned to what ever pool it uses if persistent >> connections are used) per request. >> >> Now what happens when you use either a new thread, or something like >> python's thread pool (either through the new python 3 api or old python 2 >> multiprocessing.pool.ThreadPool class)? It seems like connections are >> correctly opened, and commited if any data modification query is executed, >> but it also seems like they are never returned/closed, which is not bad in >> the case of a thread pool, as you know that thread will want to have that >> connection up for as long as it lives. >> What happens exactly if the thread / thread pool dies? On postgres at >> least (with django 1.9.5) it seems like the connection is returned/closed >> in cases the whole app server is restarted, but might be left open if the >> thread unexpectly dies. >> >> With postgres I have been experiencing some issues with connections >> leaking, my app uses some thread pools that are basically started with >> django. Now I can't really find the source of the leak, as the connections >> are correctly closed if I restart the machine (I'm using amazon cloud >> services), and it seems that they are also correctly closed on app updates >> which basically means restarting Apache, but in some very specific cases, >> those thread pools ends up leaking the connection. >> >> Does django have any code to listen to thread exit and gracefully close >> the connection held by it? Also, is there any chance that a connection may >> leak if the server is restarted before a request is finished? As it seems >> like django returns the connection only after a request is over on those >> cases. >> >> Also, if the connection gets corrupted/closed by the server, does django >> re try to open it or is that thread's connection dead for ever and >> basically the thread unusable? >> >> There's really not a lot of documentation on what happens when you use >> django's ORM on threads that are not part of the current request, hopefully >> I can get pointed to some code or docs about this. >> >> There's a good response here >> http://stackoverflow.com/questions/1303654/threaded-django-task-doesnt-automatically-handle-transactions-or-db-connections >> >> about some issues with threads and django connections but it seems old. >> >> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/9c330b4b-ebd7-4abb-b03d-dffa21d245af%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/9c330b4b-ebd7-4abb-b03d-dffa21d245af%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/3a77c0c3-4a57-470e-8ee2-8805ec4d7e35%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
