Aymeric, I have never said anything about connection pool, I'm talking about thread pooling to perform async work (without the need to spawn a new thread every time and have control over the amount data that is offloaded) and the behaviour of django connections when used on a separate thread that's not part of the request/response cycle, since if you don't take care, everything will work as expected because django is nice enough to open db connections for you even if it is from a user spawned thread, but it won't close them for you, so when working with user spawned threads special care needs to be taken on the db connections.
I have added changes to the thread's pool code so it always wraps functions between connection.close_if_unusable_or_obsolete() so the thread pool threads can always have a healthy connection and hopefully close invalid ones. I don't know if this is related to the connection leak I got that I can't seem to reproduce now but I will be keepin an eye. It would be good to have a big warning on the django docs about doing queries on threads that are spawned by the user and are not part of a request/response cycle, leting the users know they have to explicitly close them. El viernes, 3 de junio de 2016, 10:01:38 (UTC-3), Aymeric Augustin escribió: > > Hello, > > I have to say that, as the author of the “persistent connections” feature, > I am confused by repeated references to a “connection pool” in this > discussion. I chose *not* to implement a connection pool because these > aren’t easy to get right. Users who need a connection pool are better off > with a third-party option such as pgpool. > > When persistent connections are enabled, each thread uses a persistent > connection to the database — as opposed to one connection per HTTP request. > That said connections aren’t shared or pooled between threads. This > guarantees that each connection dies when the thread that opened it dies. > > In practice, Django opens a database connection per thread and keeps it > open after each request. When the next request comes in, if the connection > still works (this is tested with something like “SELECT 1”) and its maximum > age isn’t reached, Django re-uses it; otherwise it closes it and opens a > new one. This is what the “close_if_unusable_or_obsolete” function does — > as the name says :-) > > I hope this helps, > > -- > Aymeric. > > -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/78b396c7-3085-416a-9fa9-568e4aedf836%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
