Re: ActiveRecord 3.0, 3.2 thread safety and connection pool fairness

Last I looked at the AR DB connection pool, it never released
connections for active threads. That means you MUST have at
least as many connections in your pool as you have active
threads.

We are calling ActiveRecord::Base.clear_active_connections! after
each request. Rails should do this automatically.

See

In a web app, the threads are often short lived, and the
connections they occupy are released when the thread dies.
This is not the case for long-lived threads in a non-web app.

In a Java servlet container such as Tomcat, Glassfish, Jetty,
etc., there is typically a thread pool of long-lived threads
servicing HTTP requests, even if each request is short. These
are not short-lived threads performing misc. background tasks;
these are the equivalent of, for example, multiple Unicorn worker
processes, except in JRuby they can be threads.

In my particular case, I’m running several JRuby apps in the same
servlet container and sharing the same thread pool. Each app has
its own database and connection pool however.


Patrick M.

Here is a small writeup with some nicer data:
http://polycrystal.org/2012/05/24/activerecord_connection_pool_fairness.html