I've started a refactoring working towards creating a proper
connection pool class/object for ActiveRecord. Progress can be found
in my connection_pool branch on github . Some notes about the work:
- One connection pool object created and cached per
- Connection pool manages the individual connections. Currently it's
still a hash of connections per thread but it should be easy to move
to a proper fixed pool with connection acquire/release functionality.
- At some point, in order to leverage fixed-size connection pools,
we'll need to find a way for application code to notify the pool that
it's done with the connection. A controller after_filter is one
possibility, I'm interested to hear other thoughts as well.
- Connection API has not changed significantly, but I hope to at least
make the connection pool API more sane and deprecate and/or remove a
lot of the cruft like
etc. Anyone who uses these or knows the original intent of these,
please let me hear more about it. Their purpose seems less clear in
light of the refactoring so far.
- Synchronization monitors have been introduced around both connection
pool and connection access through a new active_support Module
extension I wrote that lets you easily apply synchronization at the
- allow_concurrency now simply flips between a real and null monitor
for connection pool access.
- The synchronization overhead is small, enough that I'm wondering
what people think about possibly making allow_concurrency default to
true (favoring safety over a small boost in speed of connection
acquisition). I ran the AR tests for mysql, postgresql and sqlite3
with master and my branch: