Opened 12 years ago
Closed 12 years ago
#20215 closed New feature (fixed)
Consider disabling persisent connections by default
| Reported by: | Aymeric Augustin | Owned by: | Aymeric Augustin |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Release blocker | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Discussion here: https://groups.google.com/d/msg/django-developers/rH0QQP7tI6w/I_R0JV8suSkJ
We must adress this one way or another before 1.6.
Change History (4)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
<carljm> mYk: I think that's the right answer on #20215 (disabling by default).
comment:3 by , 12 years ago
| Status: | new → assigned |
|---|
comment:4 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Note:
See TracTickets
for help on using tickets.
I'm now leaning towards disabling persistent connections by default, and suggesting them in the deployment checklist.
They're useless in development, because the development server spawns a new thread for each request. Worse, if the GC doesn't jump into action fast enough, it's easy to exhaust the number of available connections, and the result is a failure to load some static files. Annoying and non-obvious.
Also, I'm not comfortable with the idea of breaking the sites of people who won't read the release notes, won't understand the consequences for them, or (gasp!) use runserver in production (some might be doing that in spite of our warnings).