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

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Patrick Mahoney (Guest)
on 2012-05-24 16:16
(Received via mailing list)
> 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.


> 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 Mahoney
Patrick Mahoney (Guest)
on 2012-05-25 16:34
(Received via mailing list)
Here is a small writeup with some nicer data:
This topic is locked and can not be replied to.