connects_to and four real connection pools

The mid-level course "Solid Queue: job architecture" looked at eleven tables: solid_queue_jobs, its claims, its concurrency rows. None of them is reached through ApplicationRecord. They sit behind SolidQueue::Record, a different base class on a different connection. This lesson looks at that separation at the connection level, before the rest of the course asks which database each connection points at.

Four model base classes, four roles

ApplicationRecord.connection_db_config.name       # => "primary"
SolidQueue::Record.connection_db_config.name       # => "queue"
SolidCache::Entry.connection_db_config.name         # => "cache"
SolidCable::Message.connection_db_config.name        # => "cable"

These values come from the app's loaded classes. ApplicationRecord, the parent of every model the app defines, Catalog::Course included, uses the primary role. Solid Queue, Solid Cache and Solid Cable each define their own base class, and each one calls connects_to database: { writing: :queue } (or :cache, or :cable) instead of keeping the default.

These are separate connection pools

Once each base class has connected, the connection handler lists one pool per role:

[ApplicationRecord, SolidQueue::Record, SolidCache::Entry, SolidCable::Message].each(&:connection)
ActiveRecord::Base.connection_handler.connection_pool_list(:writing).each do |pool|
  puts "pool: #{pool.db_config.name} -> #{pool.db_config.database}"
end

In development (database names shown as app_development* placeholders):

pool: primary -> app_development
pool: queue -> app_development_queue
pool: cache -> app_development_cache
pool: cable -> app_development_cable

That's four independent pools, not one pool serving four table prefixes. Each takes its size from the pool: setting its role inherits in config/database.yml, and in production the queue role sets its own, sized for the job workers' threads. A SolidQueue::Job.create! and a Catalog::Course.create! never compete for the same connection slot, because they never share a pool.

Why this comes before the database names

Every lesson ahead asks one question from different angles: given four separate pools, which databases do they point at, and does the answer change with the environment? This lesson's job was narrower: show that the separation is real at the connection level, whatever database name comes next.

Key takeaways

• SolidQueue::Record, SolidCache::Entry and SolidCable::Message each declare their own connects_to, resolving to "queue", "cache" and "cable", distinct from ApplicationRecord's "primary".
• connection_handler.connection_pool_list shows four independent pools, one per role, each sized by the pool: setting that role inherits or overrides.
• The separation happens at the Rails connection layer, before any question of which physical database a pool targets.
• The rest of the course looks at where each pool points in development, test and production.