Sam Saffron
2012-Nov-28 20:00 UTC
Feature Request: Add support for multiple, concurrent, connection pools
Since, https://github.com/rails/rails/issues/8344 was closed, raising this here: see: http://stackoverflow.com/questions/13598583/active-record-and-multi-threading-involving-multiple-dbs I have a Rails app that is multi homed. foo.mysite.com talks to the "foo" db. bar.mysite.com talks to the "bar" db. This is accomplished by calling: ActiveRecord::Base.connection_handler.establish_connection("ActiveRecord::Base", foo_spec) When requests come in for foo it uses the foo_spec, when requests come in for bar it uses the bar_spec. Everything is happy and there is peace in the world. However, I also use sidekiq, it is heavily multi-threaded. I was getting weird behavior in sidekiq. Often when I thought I was talking to the foo_db,ActiveRecord::Base.connection was pointed at bar_db. I dug into the code and found: def retrieve_connection_pool(klass) pool = @class_to_pool[klass.name] return pool if pool return nil if ActiveRecord::Base == klass retrieve_connection_pool klass.superclass end Turns out the internal design of AR only allows AR::Base to know about a single connection pool. Is there any way to get thread 1 to talk to db1, and thread 2 to talk to a db2 at the same time, usingActiveRecord::Base.connection ? Am I missing something about the design? Has anything changed in 4? I do not really want to have to resort to adding a "special" base class that adds this, as I would be risking certain gems that talk to ActiveRecord::Base.connection breaking. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/p_SEqhi7CTMJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.