Can I use ActiveRecord for a threaded TCP server?

Dear list,

I know that rails is told to be not thread safe. Does anybody know if that
includes all parts of rails or just some? I'm looking for a way to accept TCP
connections in a separate runner process and want to store/modify
ActiveRecord objects.

In a few examples, I saw that it's common to accept a connection and create a
new (ruby-) Thread to do the communication for each connection. Could I use
ActiveRecord in a thread there, or would that open the risk of a race
condition?

If that doesn't work out, would it be ok to create a single thread to do the
ActiveRecord stuff and let the other threads use it and protect it with a
monitor?

If that's still dangerous, I suppose I have to create a second runner process
for ActiveRecord (a fork()ed one should do, I suppose) and let it accept jobs
by looking for spool files created by the threads of the TCP process. However
this wouldn't be a very nice solution. :-/

regards,
Andreas Neuhaus

Yeah ActiveRecord can work with multiple threads like this if you set ActiveRecord::Base.allow_concurrency = true. One thing to make sure of is to kill the database connection at the very end of each thread before you reap it. This will keep you from getting a too many open connection error. I have experimented and if you start a process and load up ActiveRecord and connect to the db, then you spawn threads, they each seem to get their on db connection that you can kill at the end of the threads life without affecting the other connections.

  You may want to look at my plugin BackgrounDRb[1] that is a multi threaded worker pool that uses ActiveRecord in threads for ideas.

Cheers-
-Ezra
[1] http://backgroundrb.rubyforge.org

Note that you risk deadlock with all adapters except PostgreSQL and Oracle even with a carefully managed thread pool since their underlying API don’t use nonblocking IO. A process pool is safer.

This is a strong poing in favor of top-quality pure-Ruby database drivers: they can cooperate with Ruby’s select to simulate a nonblocking API. Unfortunately, the native bindings are faster and more compatible for general use.

Best,
jeremy