Jon Tirsen has taken a closer look at the differences between the threaded scaling approach in J2EE and using Rails with FastCGI. While the former requires object pools, induces thread-safety concerns, and other complications, the FastCGI approach remains dead simple from the application programmers perspective:

This means that each process can pre-allocate one single database connection (for each database that it talks to). There are no issues of multi-threading as each process processes only one request at a time. No objects needs to be written to handle multi-threading, as there is just one single thread per process. Expensive resources doesn’t need to be allocated in pools and application code doesn’t need to return the resources once done with them. Complicated non-blocking IO solutions or muxer/demuxer architectures doesn’t need to be used. You can even allocate FastCGI processes on multiple physical nodes, effectively implementing a cluster. In high-security situations a double-firewall security architecture can be set up so that the web-server is protected by one and the back-end FastCGI servers are protected by an additional one.