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: 1) 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. 2) 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
on 2007-07-05 22:23
on 2007-07-05 23:11
there's already a plugin that tackles this problem. check out backgroundrb (http://backgroundrb.rubyforge.org/) for more info Mike
on 2007-07-06 00:23
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
on 2007-07-06 16:12
Mike Garey 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
on 2007-07-06 16:28
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 Rochkind <firstname.lastname@example.org> 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
on 2007-07-09 16:45
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.
on 2007-07-09 20:37
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.