Expensive request processing

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.