Forum: Ruby on Rails Rails / ActionPack thread safety

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Christian R. (Guest)
on 2006-05-30 16:19
(Received via mailing list)
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...????
Paul W. (Guest)
on 2006-05-30 17:43
(Received via mailing list)
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-...
Christian R. (Guest)
on 2006-05-30 19:07
(Received via mailing list)
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-...

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...????
Ezra Z. (Guest)
on 2006-05-30 21:02
(Received via mailing list)
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-...
>
> 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
Justin F. (Guest)
on 2006-05-31 03:42
(Received via mailing list)
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-...

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) :-)

regards

   Justin
This topic is locked and can not be replied to.