Hacker News Reader

Comment by fotcorn | Hacker News Reader

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

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.)

Looks like a no-go for unicorn deploy https://groups.google.com/forum/#!msg/django-developers/rH0Q...

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.

We're really looking forward to this. We'll still use pgbouncer, but we think we may see a slight boost.

It's not connection pooling.

Care to explain what it is?

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".

Thanks for the detailed answer.

In what scenario can this be used?

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.

It is "Persistent database connections" just like it says it is.

Reply on news.ycombinator.com