Comments on: Connection Management in ActiveRecord

By: Andreas

Andreas — Tue, 15 Nov 2011 16:29:55 +0000

An immediate result thanks to your talk about this at rubyconf in Uruguay. http://t.co/llY4HVCQ

By: Our Geek Space » Blog Archive » It’s about timing baby!

Our Geek Space » Blog Archive » It’s about timing baby! — Tue, 15 Nov 2011 13:44:50 +0000

[...] is no free connection it iterates over all the threads to take back the connections of dead threads(more info). See the correlation with the 5 seconds I talked about in the previous paragraph? We immediately [...]

By: Multi-threaded use of Rails ActiveRecord 3.0-3.1 | Bibliographic Wilderness

Multi-threaded use of Rails ActiveRecord 3.0-3.1 | Bibliographic Wilderness — Mon, 14 Nov 2011 19:31:44 +0000

[...] When I say “old rails” I mean Rails/Active Record 2.1, before the introduction of the ConnectionPool. When I say “new” or “current” Rails, I mean Rails 3.0 or 3.1 In fact, the ConnectionPool was introduced in Rails 2.2, so the general principles may apply starting then, however there have been continual tweaks to ConnectionPool for bugs, robustness, and performance, so using Rails 3.0 or 3.1 is recommended. Rails 3.2 does not yet exist at time of this writing, and may completely change the game yet again, if Aaron tenderlove goes forward with his ideas for a major refactor. [...]

By: Seraf

Seraf — Fri, 04 Nov 2011 16:48:11 +0000

Fuck you, with love.

Keep writing, I won’t read you.

By: apneadiving

apneadiving — Wed, 02 Nov 2011 21:11:26 +0000

Thanks for your job and your peculiar, yet lovely, weirdness

By: Jérémy Lecour

Jérémy Lecour — Fri, 28 Oct 2011 07:38:40 +0000

Thanks Aaron for making this kind of deep analysis of non fancy parts of the framework.

I’d really like to run into you in a coffee shop and hug you Swayze-style

BTW, this hug thing inspired me to offer some free pair-programming time to people who’d like to have some kind of guidance. Thanks for that idea too.

By: This Week’s Top Ruby News: JRuby 1.6.5, A New Prag Prog Book, Fast Specs, Rails Style Guide and More

Thu, 27 Oct 2011 16:30:19 +0000

[...] Connection Management in ActiveRecord (and How To Improve It) Aaron 'tenderlove' Patterson talks about database connection management in ActiveRecord, how he's not pleased with it, and how he wants to step towards fixing it to be more like File's API. [...]

By: TVD

TVD — Thu, 27 Oct 2011 14:44:55 +0000

Quote:
“[R]educe code complexity and at the same time increase the features available.”

+1 if this is why you love Rails!

Go for it Aaron!

By: Ken Collins

Ken Collins — Tue, 25 Oct 2011 14:13:36 +0000

Being an ActiveRecord adapter author, the connection pool is something that still boggles my mind every now and then. I’ll point out a few oddities I have had and followup with a few questions that hopefully Aaron or someone can help me with.

First, you talked a bit about the #establish_connection method. One thing I was bitten by many years ago was using #establish_connection too much. I don’t think that many people understand that if you have a base configuration and you call establish_connection(:legacy_db) in say 3 models, you end up with 3 distinct connection pools for those models. If you have callbacks that touch other models, bam, deadlock. The current practice that I do not see documented much and that I tell my adapter users to do is to make a model that champions the connection and subclass from that. Something like this: https://gist.github.com/1312844 This is a contrived example when your application needs to talk to 2 or more databases.

So my first question what would the pattern look like in your solutions? Would #establish_connection work like I thought many years ago and not create a pool per class. Is #establish_connection the only time where classes end up with a connection pool?

Second question is related to connection pool size. In my mind, a basic non thread-safe rails application would never end up with a connection pool larger than 1. I have found that in some cases in a large 5-year old rails application, that the pool grows and setting it to 1 would not allow the app to work. Why? Is this related to ActionPack or some other middleware checking things back in?

P.S., I love the config.i_suck_and_will_not_close_my_database_connections, reminds me of MiniTest’s #i_suck_and_my_tests_are_order_dependent!

By: Gabriel Sobrinho

Gabriel Sobrinho — Sat, 22 Oct 2011 13:08:36 +0000

Aaron Patterson,

This sounds great!

I made a gem to handle multiple connections (I’m dealing with an application where each customer have your own dedicated database) and I guess the code is so bad because I can’t handle active record in a great way.

The only way I found is monkey patching 2 methods of active record, take a look: https://github.com/sobrinho/activerecord-connections/blob/master/lib/active_record/connections.rb

I guess your idea will handle this situation and the gem will not be necessary anymore, right?