Rails / ActionPack thread safety


#1

Hi all,

Both the rails book (1st Ed) and the docs on the rails site (and the
Mongrel FAQ) tell me that rails (& ActionPack /ActiveRecord) is not
threadsafe. Since I need lots of worker threads in the app I’m working
on
(details at the end of this mail) this poses quite a problem for me.

Is the lack of thread safety a conscious design decision (kind of
understandable for rails as such, but IMHO strange for ActiveRecord) or
just something nobody has found the time to take care of yet? Is there
any documentation on what exactly lacks thread safety? From
http://wiki.rubyonrails.org/rails/pages/HowTosWorkerThreads I got the
impression that it’s mainly a lack of connection pooling in
ActiveRecord,
which (in theory) shouldn’t be too difficult to fix…

Some details on my project:

It’s a tool taking care of (in the future) most of the administrative
work
at http://dotsrc.org/ – setting up mirrors, handling their automatic
updates, setting up hosted projects, adding / modifying users etc.

The “down to the metal” functionality is done in a distributed daemon
(one
instance per server, one of them a designated “master” containing stuff
like an internal cron and channeling all requests from the frontend).
The
frontend is basically a normal rails application.

Since both of these parts share a large part of the code (e.g. the
complete database model), I’m implementing them as “2-in-1” rails app,
i.e. same lib/, app/models, etc, but different
app/(frontend|backend)/(controller,view,helper) and different startup
scripts. Works fine so far, and allows me to make good use of rails
(like
using it (with ActionWebService) also for the frontend <-> backend
communication).

I’m porting the app from a custom-baked framework over to rails.


Christian R.

…10001000110101011010101101011110111010113…???


#2

On 30/05/06, Christian R. removed_email_address@domain.invalid wrote:

any documentation on what exactly lacks thread safety? From
http://wiki.rubyonrails.org/rails/pages/HowTosWorkerThreads I got the
impression that it’s mainly a lack of connection pooling in ActiveRecord,
which (in theory) shouldn’t be too difficult to fix…

Zed posted on this subject recently on the mongrel-users list:

http://rubyforge.org/pipermail/mongrel-users/2006-May/000302.html


#3

On Tuesday 30 May 2006 15:42, Paul W. wrote:

understandable for rails as such, but IMHO strange for ActiveRecord)
or just something nobody has found the time to take care of yet? Is
there any documentation on what exactly lacks thread safety? From
http://wiki.rubyonrails.org/rails/pages/HowTosWorkerThreads I got the
impression that it’s mainly a lack of connection pooling in
ActiveRecord, which (in theory) shouldn’t be too difficult to fix…

Zed posted on this subject recently on the mongrel-users list:

http://rubyforge.org/pipermail/mongrel-users/2006-May/000302.html

Hmm, ok. If there’s really a fix for ActiveRecord already, that would
solve most of my problems (my worker threads don’t need controller/view
magic). Thanks.


Christian R.

…10001000110101011010101101011110111010113…???


#4

On May 30, 2006, at 8:04 AM, Christian R. wrote:

Is the lack of thread safety a conscious design decision (kind of
http://rubyforge.org/pipermail/mongrel-users/2006-May/000302.html

Hmm, ok. If there’s really a fix for ActiveRecord already, that would
solve most of my problems (my worker threads don’t need controller/
view
magic). Thanks.


Christian R.

…10001000110101011010101101011110111010113…???

Christian-

You also might want to take a look at my BackgrounDRb plugin. it is

written for exactly this kind of managed background task work and has
hooks for ajax progress bars for showing status or progress in the
browser while the worker tasks run in a separate daemon. I am using
it for sysadmin stuff very similar to what you describe.

You can find out more information or subscribe to the mailing list

here:

 # Mailing List
 http://rubyforge.org/mailman/listinfo/backgroundrb-devel
 # rubyforge project
 http://rubyforge.org/projects/backgroundrb/
      # README
    	http://backgroundrb.rubyforge.org
 # Blog
 http://brainspl.at

Cheers-
-Ezra


#5

Paul W. wrote:

just something nobody has found the time to take care of yet? Is there
any documentation on what exactly lacks thread safety? From
http://wiki.rubyonrails.org/rails/pages/HowTosWorkerThreads I got the
impression that it’s mainly a lack of connection pooling in ActiveRecord,
which (in theory) shouldn’t be too difficult to fix…

Zed posted on this subject recently on the mongrel-users list:

http://rubyforge.org/pipermail/mongrel-users/2006-May/000302.html

Paul, and Zed, thank you so much. I’ve been interested in the answer to
this for the best part of a year, and there has never been a proper
explanation on the Rails list.

From what Zed wrote, this comment in action_controller/base.rb:

 # Controls whether the application is thread-safe, so

multi-threaded servers like WEBrick know whether to apply a mutex
# around the performance of each action. Action Pack and Active
Record are by default thread-safe, but many applications
# may not be. Turned off by default.
@@allow_concurrency = false
cattr_accessor :allow_concurrency

should be taken with a large pinch of salt (or something stronger) :slight_smile:

regards

Justin