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?
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.
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.