My connection pooling branch is getting close to being ready for
merging. At this point, I'd appreciate help in trying it out in real
applications and seeing how it behaves, as well as reviewing the code
and documentation. As far as the code goes, 95% of the changes are in
Database/connection pool configuration is as follows.
1. With no changes to database.yml, the connection pooling code falls
back into a cached connection-per-thread compatibility mode. Try your
app with this first, and make sure everything still works as expected.
2. To try out the fixed size connection pool, add a "pool: N"
attribute to the configuration (yaml below, or in ruby if that's your
pool: 4 # share a maximum of 4 connections
In order to take advantage of the pool, you actually need to return
connections to the pool after each request. Eventually this should be
baked into ActionPack, but for now you need to add this bit of code to
app initialization. (Note that this can also be used in #1 without any
There's also a "wait_timeout" database config attribute that controls
how long the thread will wait for a connection when the pool is
exhausted (default is 5 seconds). If a thread times out waiting for a
database connection, an ActiveRecord::ConnectionTimeoutError (subclass
of ConnectionNotEstablished) is raised.
In the cleanup/deprecation department, I'd like to propose getting rid
of allow_concurrency. If you look at the code currently you'll see it
does have an effect -- it basically adds synchronization around
connection handling methods. But just mentioning allow_concurrency
brings up legacy thoughts of past hacks that didn't really cut the
multi-threaded string cheese. So if possible I'd like to see if
there's a way to handle both single and multiple thread use cases
without it, even though I don't have a good idea yet of how to do
As always, comments appreciated.