ActionController::Dispatcher.after_dispatch do
ActiveRecord::Base.clear_reloadable_connections!
end

I am a recruiter employed with Follett Software Company and Follett Digital Resources http://www.fdr.follett.com (both educational technology businesses) in the Chicago, IL area. We are currently seeking a full time or contract-to-hire Senior PHP/Ruby on Rails developer due to the growth of our business. I have tried many sourcing/networking options to find this type of talented candidate, but it has been difficult. Do you have any ideas? We are willing to assist in relocating the selected candidate. Here is a link to the position. Any ideas would be greatly appreciated. Thank you.

http://www.follett.com/careers/showjobdesc.cfm?jobid=7363

Andrea Minard
Senior Recruiter

Is what are the performance difference between running a Rails app in Tomcat vs Glasshfish ? We are looking to deploy our first app under JRuby. I think that Glassfish would be a better solution, but I need “proof” :)

Have you experimented with dedicating a DB connection to each JRuby instance, with no connection pooling at all? Assuming you periodically cycle the JRuby instances, and thus, periodically cycle your DB connections, it seems to me that you would get all of the same benefits. Or is it the case that DB connections need to be dropped and recreated more or less frequently than JRuby instances?

This post helps as well:

http://blog.headius.com/2008/08/qa-what-thread-safe-rails-means.html

“In a typical Mongrel setup, handling 10 concurrent requests means you have to have 10 copies of Rails loaded, 10 copies of your application loaded, 10 in-memory data caches, 10 database connections…everything has to be scaled in lock step for every additional request you want to handle concurrently.”

The connection is established by ActiveRecord::Base when the server boots up (railties/lib/initializers.rb). The connection itself can be retrieved with ActiveRecord::Base.connection. In the initialization step, the appropriate ActiveRecord adapter is loaded. In this example, the adapter is the JDBC adapter.

The reason Rails does not natively support connection pooling is because Rails is single-threaded, and therefore only really needs one connection per database. If each process has only one connection, there’s no need for a pool. In the example above, multiple separate Rails instances run inside a Glassfish container. Without connection pooling, N instances would create N connections.

Rails 2.2 is going to be interesting. The big feature coming is threaded Rails. I’ve heard talk of building connection pool management directly into Rails. I’m curious to see how this will play out with regards to JDBC pooling.

Hi Loc, my group is definitely hiring. Check out this link:

http://www.linkedin.com/jobs?viewJob=&jobId=595885

If you’re interested in looking at our available engineering positions, you can find them here. I’m happy to report that LinkedIn Engineering is one of those places that lives on the cutting edge. If you like diving into new technologies to complement the proven ones, you’ll be up to your neck in them here.