On Thu, Jul 23, 2009 at 10:02 PM, Carlos A. Carnero Delgado<carloscarn...@gmail.com> wrote: > On Thu, Jul 23, 2009 at 5:24 PM, Glenn Maynard<gl...@zewt.org> wrote: >> Why is each thread's database connection closed after each request? > > I believe that this is related to Django's shared-nothing-by-default approach.
In this case, that's a terrible-performance-by-default approach. (It's also not a default, but the only behavior, but I'll probably submit a patch to add a setting for this if I don't hit any major problems.) I can think of obscure cases where this would matter--if something changes a per-connection setting, like changing the schema search path, and doesn't put it back--but for most people this is just an unnecessary chunk of overhead. (I wonder if Postgres has a way to quickly reset the connection state, without having to tear it down completely.) The only other change I've had to make so far is making TransactionMiddleware always commit or rollback, not just on is_dirty, so it doesn't leave read locks held after a request. (Of course, that sometimes adds an SQL COMMIT where there wasn't one before, but I'll take a 500us per request overhead over 100ms in a heartbeat.) -- Glenn Maynard --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
