3 ms·

Integrated connection pooling makes this release a no-brainer upgrade on release day.

• acjohnson55 13y ago
  Agreed! The changes to transaction management seem pretty solid too. I've found transactions to be pretty somewhat unpredictable at times in the past, so I'm encouraged by these changes.
• gtaylor 13y ago
  We're really looking forward to this. We'll still use pgbouncer, but we think we may see a slight boost.
• ubernostrum 13y ago
  It's not connection pooling.
  • rattray 13y ago
    Care to explain what it is?
    • ubernostrum 13y ago
      Currently, Django closes the database connection at the end of each request/response cycle. In 1.6, Django will optionally not do this; instead, a setting can specify the maximum amount of time to hold open and keep reusing an existing connection. This is not connection pooling; that would imply some functionality to actively maintain and allocate connections. This is simply "your process will hold its connection open from one request/response cycle to the next".
      • pajju 13y ago
        Thanks for the detailed answer. In what scenario can this be used?
        • mik3y 13y ago
          Think of it as an optimization: Previously, each request meant a new db connection had to be opened. Now a prior connection can be reused.
• mixmastamyk 13y ago
  It is "Persistent database connections" just like it says it is.
• dmishe 13y ago
  Looks like a no-go for unicorn deploy https://groups.google.com/forum/#!msg/django-developers/rH0QQP7tI6w/I_R0JV8suSkJ https://groups.google.com/forum/#!msg/django-developers/rH0Q...
• bhauer 13y ago
  Thank goodness. Not being a user of the framework, the lack of database connectivity persistence in Django was among the most surprising elements of setting up the initial test cases in our framework benchmarks project. We've since then added a Postgres test with a connection pool, but I still have the memory of that surprise from the first round. (Incidentally, I hope to get this new version into Round 7 of our project.)