Active Records - multiple connections question

Hi List,

I figure that rails is the most appropriate board to post this in, tho
my problem is not necessarily rails-specific, but rather an active
records issue.

So here goes:
I am working on an ruby-implementation of an API to a large genome
database. This database is in reality split into multiple database, one
for each sequenced genome. There is on ‘central’ database that holds
comparative data between genomes and references the corresponding
organism-specific database for fetching the actual data.

Connecting to any of these genomes works by specifying the organism name
in the connection method
SomeModule::DBConnection.connect(‘homo_sapiens’). So the Module/Class is
always the same, except the organism name which specifies which database
to connect to.

What happens tho if I try to fetch data from multiple genomes in a row
is that the ruby process locks up eventually. I am guessing it has
something to do with active records and how it manages these
connections. For example, I am not using (and don’t know how) a
termination signal that would close the old connection as I figure that
this shouldn’t be an issue if a new one is created to replace the old
one (?).

Anyhow, I know this may be a little confusing but I guess you get the

My question is: What to do about this issue (multiple database
connections in rapid succession via the same DBConnection class) - is
there a more sophisticated way to handle this? Also,optional question,
how does one properly deal with dropped connections (which could be part
of the issue)?


You could try forcing a garbage collection with something like
GC.start (I think). You could try doing that after each connection,
or after every N connections, if it takes too long.


The optional question should be pretty easy to solve.
ActiveRecord::Base has a method called ‘connected?’.

I am not that experienced with multiple connections, though, so I’d
rather let somebody else give you an more intelligent answer than I


On Sep 3, 1:32 am, Marc H. [email protected]