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 [1]. Some notes about the work:
- One connection pool object created and cached per AR::Base.establish_connection call. - 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 active_connection/clear_active_connections!/clear_reloadable_connections!/verify_active_connections! 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 method level. - 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: master ====== test_mysql: 43.058775 seconds. test_sqlite3: 39.885374 seconds. test_postgresql: 36.002755 seconds. nicksieger/connection_pool ====== test_mysql: 44.72238 seconds. test_sqlite3: 40.68397 seconds. test_postgresql: 37.23015 seconds. nicksieger/connection_pool w/ default allow_concurrency = true ====== test_mysql: 45.641348 seconds. test_sqlite3: 43.405034 seconds. test_postgresql: 37.850598 seconds. (This is of course not an exhaustive benchmark, but at least gives you an idea.) This might seem like YAGNI for a lot of you, but I think it has the dual benefit of cleaning up the connection_specification code, plus supporting the endgame for my standpoint, which is making the connection pool implementation pluggable so that I can use the Java application server's connection pool when running with JRuby. Comments appreciated! /Nick [1]: http://github.com/nicksieger/rails/commits/connection_pool --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
