Re: Threads and db connection handling question

Some of the pools might have some high load (such as the one that handles logging to the database and other sources) so opening and closing a connection for each call might end up bad. Now that you mention django code, does connection.close_if_unusable_or_obsolete() always close the connection,

Re: Threads and db connection handling question

Do you expect your background threads to be equivalent to or greater than the number of requests you're normally servicing? Usually background tasks are much less frequent than the web requests, so a little overhead w/r/t database connections isn't even going to be noticed. Looking at what Django

Re: Threads and db connection handling question

I'm not starting threads by hand but rather a pool which handles any threads for me, I basically just send a function to the pool and leave it run. You are right, I could wrap every function sent to the pool with the code you proposed, but I also don't want to open and close a connection on ever

Re: Threads and db connection handling question

I'm still a bit confused. What is the advantage of having connections closed automatically when the thread exits? It seems to me that you can quickly solve your problem by modifying your thread start routines: from django.db import connection from contextlib import closing def my_thread_start():

Re: Threads and db connection handling question

Florian, Sorry about the SIGTERM and SIGKILL confusion, I think I read somewhere some time ago that SIGTERM would instantly finish any pending request, so I assumed it would also kill any thread in not a really nice way. However now that you mention it, there's one SIGKILL from the apache logs

Re: Threads and db connection handling question

On Friday, June 3, 2016 at 12:32:15 AM UTC+2, Florian Apolloner wrote: > > while getting killed with SIGTERM (dunno if the postgres protocol has keep > alive support on the protocol level, most likely not). As long as you are > not sending a SIGTERM > Ups, now I am myself mixing up SIGKILL and S

Re: Threads and db connection handling question

On Thursday, June 2, 2016 at 11:55:41 PM UTC+2, Cristiano Coelho wrote: > > 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 > A SIGTERM is a normal signal a

Re: Threads and db connection handling question

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 properl

Re: Threads and db connection handling question

On Thursday, June 2, 2016 at 5:15:55 PM UTC+2, Aymeric Augustin wrote: > > > On 02 Jun 2016, at 13:39, Cristiano Coelho > wrote: > > > > it would be great for them to be automatically closed/disposed for you > on thread's death, which right now seems to happen some times, and some > times no

Re: Threads and db connection handling question

Hi Cristiano, > On 02 Jun 2016, at 13:39, Cristiano Coelho wrote: > > it would be great for them to be automatically closed/disposed for you on > thread's death, which right now seems to happen some times, and some times > not, leaking connections (something I'm trying to figure out what's goi

Re: Some thoughts on upgrade pain & deprecations.

> I'm against adding custom behavior in Django That's entirely reasonable, yes. In which case, what do folks think of the following suggestions: * Linking prominently to the 'upgrading django ' section from at the begining of every

Re: Threads and db connection handling question

On Thursday, June 2, 2016 at 1:39:51 PM UTC+2, Cristiano Coelho wrote: > > So what was stated on the stack overflow post that connections are somehow > closed only at the end of a request through the request end signal is still > the actual behavior? > Dunno, I do not read SO. Connections are cl

Re: Some thoughts on upgrade pain & deprecations.

> > Aside: I think the `.urls = ...` -> `@override_settings(ROOT_URLCONF=...)` > change to test cases is missing from those notes? > The 1.10 release notes say, "SimpleTestCase.urls is removed." > I expected to have seen a deprecation warning when running the tests under > 1.9, although was

Re: Some thoughts on upgrade pain & deprecations.

I like the general idea. Going with your low tech solution we could have snippets for the X most popular test runners to treat warnings as errors. Perhaps ./manage test.py --warnings-as-errors or similar for the interface django provides. Every time django makes a release there are some that ex

Re: Possible Bug (MYSQL)

Hi Paulo, Have you opened a ticket on Trac for this yet? If not, please do so. This mailing list isn't really for verifying bugs. That said, does the query work if you provide an actual alias for the aggregate? *Company.objects.annotate(max_pk=Max('employee__p

Re: Some thoughts on upgrade pain & deprecations.

The low tech solution to this, may just be to have the release notes recommend running your test suite using `PYTHONWARNINGS=once`, and making sure not to swallow any output, eg. with py.test that'd be... PYTHONWARNINGS=once py.test tests -s I'm fairly sure that making that point explicitly wo

Re: Threads and db connection handling question

So what was stated on the stack overflow post that connections are somehow closed only at the end of a request through the request end signal is still the actual behavior? Any best / suggested practices on how to handle connections on threads that are not part of the request cycle? Considering

Some thoughts on upgrade pain & deprecations.

I've just finished upgrading Django REST framework to support 1.10, and it's given me some food for thought on things that can make Django upgrades painful. Firstly, here's a couple of things that I needed to track down in order to upgrade that weren't obvious at first... * A bunch of test vie

Re: Threads and db connection handling question

Hi, Django does not really use a Pool from which you can check out connections and return them back to the pool. Every thread has it's own connection which is initialized on first use -- there is nothing which closes connections (or checks for their lifetime with persistent connections) automa