> - One connection pool object created and cached per > AR::Base.establish_connection call.
Excellent! > - 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. This will be the biggest change, we can do implicit checkout of a connection when trying to access the database for the first time in a thread, but implicit checkin seems to be asking for trouble. We can handle it for ActionController easily enough by checking the connections back in after the request has been dispatched. So my first thought is: Foo.find(:first) # retrieves connection Thread.new do Foo.find(:first) # retrieves another Bar.find(:first) # uses existing ActiveRecord::Base.release_connection Foo.find(:first) # retrieves another end With retrieving blocking until the connection is available. > - 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. There are two cases that I'm aware of that lead to those 'interesting' methods. * Reloading in development mode (the classes get undefined, so the connection is gone) * re-establishing timed out connections. By moving the connections to the pool rather than the classes that get reloaded, we avoid the first problem. Obviously checking out a connection should imply that its been verified. So with a proper 'pool' we can avoid all those methods, and improve the code for the simple one-thread case too. > 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. The code cleanup is pretty desperately needed, it's some hokey nasty stuff ;). The dual benefit of getting jruby connection handling a little easier is a definite win. > Comments appreciated! Rather than swapping in and out a different monitor, why not have two different connection handler classes, one of which returns and manages a single connection, and another which manages a pool of a fixed size. The single connection version can expose the same API (checkout / check in / release) and perhaps raise exceptions if accessed from threads other than the one which created the connection. new-connection-per-thread isn't a particularly great idea and I'd be open to dropping it entirely. Thanks for your work on this, it'll be good to tidy this up. There are still a bunch of outstanding issues to be decided, especially relating to objects retrieved in one thread and being worked-on in another. This messes up :lock=>true etc. But let's tidy up the code first, then decide what level on concurrent use we want to support. > /Nick > > [1]: http://github.com/nicksieger/rails/commits/connection_pool > > > > -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
