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.