I''m trying to decide between Rails and Seam (a Java framework) for an application whose main traffic will be PUT requests, with lengthy text parameters that will need to be parsed, split apart, and update multiple records. This could be quite CPU intensive, and I''m worried about ActiveRecord being single-threaded. I can''t put the processing in a background thread because of this. Any thoughts? Would I be able to use native SQL in a background thread? -- 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''m trying to decide between Rails and Seam (a Java framework) for an > application whose main traffic will be PUT requests, with lengthy text > parameters that will need to be parsed, split apart, and update > multiple > records. This could be quite CPU intensive, and I''m worried about > ActiveRecord being single-threaded. I can''t put the processing in a > background thread because of this. Any thoughts? Would I be able to > use native SQL in a background thread?You may want to look at Merb as well. --~--~---------~--~----~------------~-------~--~----~ 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''m using backgroundrb, which is not (strictly speaking) a thread. It''s distributed Ruby, and runs in a separate process, but the usage is almost exactly as you would expect with threads. Because the processes are separate, each maintains separate ActiveRecord state and you don''t have the most pernicious concurrency issue. The database should maintain coherence. Native SQL is not a problem, and if you don''t really care how long the background process takes to complete, this is just a great way to offload processing. HTH. On Jul 2, 2008, at 8:05 AM, Brenton Partridge wrote:> > I''m trying to decide between Rails and Seam (a Java framework) for an > application whose main traffic will be PUT requests, with lengthy text > parameters that will need to be parsed, split apart, and update > multiple > records. This could be quite CPU intensive, and I''m worried about > ActiveRecord being single-threaded. I can''t put the processing in a > background thread because of this. Any thoughts? Would I be able to > use native SQL in a background thread? > -- > 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 -~----------~----~----~----~------~----~------~--~---