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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
there''s already a plugin that tackles this problem. check out backgroundrb (http://backgroundrb.rubyforge.org/) for more info Mike On 7/5/07, Jonathan Rochkind <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > 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 > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Mike Garey wrote:> there''s already a plugin that tackles this problem. > > check out backgroundrb (http://backgroundrb.rubyforge.org/) for more > info > > MikeThanks. 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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > 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 > > -- > Posted via http://www.ruby-forum.com/. > > > >-- Eider Oliveira Site: http://eider.eti.br Blog: http://web.mac.com/eider.oliveira/iWeb/Home/Blog/Blog.html --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. > > []sCool, 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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Seemingly Similar Threads
- Creating another database connection for large mysql import?
- Mutex::Synchronize with backgroundrb
- postgres barfage revisted
- Broken thread Safe connection Management on Mysql (Mysql too many connections errors)
- Rails 2.2.2 - Mysql::Error: MySQL server has gone away