Let’s start out without ActiveRecord, just to make the case. So, I have
a calculation that will take a while to run in my Rails app.
One doesn’t really want to just hold a HTTP connection open until it’s
done, for a variety of obvious reasons.
Even though everyone says “Rails isn’t thread safe”, I can’t think of
any reason this would be a problem:
- Use Thread.new to kick off the long-running-calculation, and then
return a response to the browser (close connection).
1a) An object of our own special class has been put in session, this
object is synchronized and threadsafe, and has state for
long-running-calc status/progress, and results.
- Browser can check back now and then (AJAX-y, just plain
META-refresh, actual user initiated ‘check status’ link, whatever),
check this object in session (which we carefully wrote to be
thread-safe), and report back progress/results.
So long as the thread doesn’t actually use any Rails-type classes, Rails
theoretical lack of thread-safety should be irrelevant, right? This
should work fine. Correct me if I’m wrong.
But the next part is—what if the Thread does need to use ActiveRecord.
Am I asking for trouble? Should I make copies of my individual
ActiveRecord instances to give to the thread, to make sure my background
thread isn’t operating on the very same ActiveRecord object that a Rails
thread (or another background thread might be?)? Or is this not
necessary? Anything else I should be worried about?
In general, can I get away with this? Having a background thread that’s
using ActiveRecord, in Rails? And what do I need to be careful of?
Thanks so much for any advice,
Jonathan
there’s already a plugin that tackles this problem.
check out backgroundrb (http://backgroundrb.rubyforge.org/) for more
info
Mike
I am trying to figure out what would be the best route.
Is RoR the right technology to use for the following project?
I have a server that is a Solaris JumpStart server. I want to be able
to control this server through a web interface to manually setup a
lab of computers.
Regards,
Ron
Mike G. wrote:
there’s already a plugin that tackles this problem.
check out backgroundrb (http://backgroundrb.rubyforge.org/) for more
info
Mike
Thanks. To me, backgroundrb seems like WAY overkill for what I need to
do. So I’m still curious if Thread.new can work the way I’d like. [And
for that matter, looking at the archives, it looks like backgroundrb
users have had very similar questions about ActiveRecord–and possibly
run into problems?–when it comes to more than one backgroundrb thread
using ActiveRecord? So the question may be valid either way.
Jonathan
use ActiveRecord::Base.allow_concurrency = true and you’ll be cool.
I’d suggest to call
ActiveRecord::Base.verify_active_connections! from time to time or you
will end up starving on database threads.
[]s
On 7/6/07, Jonathan R. [email protected] wrote:
do. So I’m still curious if Thread.new can work the way I’d like. [And
–
Eider Oliveira
Site: http://eider.eti.br
Blog: http://web.mac.com/eider.oliveira/iWeb/Home/Blog/Blog.html
Aha, answering my own question, it looks like verify_active_connections!
is indeed the way to close all connections associated with stale
threads.
It appears to be entirely undocumented (not even mentioned in the rdoc),
but looking around in the AR source, I found it, and it appears to do
what is needed. Hmm, maybe I can get away with this after all.
Eider Oliveira wrote:
use ActiveRecord::Base.allow_concurrency = true and you’ll be cool.
I’d suggest to call
ActiveRecord::Base.verify_active_connections! from time to time or you
will end up starving on database threads.
[]s
Cool, thanks a lot I’ll give it a try. If I don’t call
verify_active_connections! (can I find this method documented
anywhere?), my code will wait (block) for an available connection, or
what?
Looking around on Google, I see there are problems with db connection
pooling in ActiveRecord, it’ll open a db connection for every thread,
and then never close it. Hmm. Maybe I am just asking for trouble here,
and really have no choice but to use Backgroundrb after all.
Backgroundrb seems awfully complicated to use to me, and other
developers have told me they had trouble with it. And I’m alarmed that
the backgroundrb web page says that the software is experimental and not
tested. But, hmm, maybe it really is the only good option.