the scheduler and the active_record

update :

I have had issues with ActiveRecord > 2.2, a bunch of jobs scheduled where “missing the train” (MySQL gone).

I placed

  ActiveRecord::Base.verify_active_connections!

at the beginning of my scheduled blocks and the issue seem to have vanished. Rails does that connection verification for each request, not for things outside of requests, have to do it by oneself.

---

The rufus-scheduler cares about scheduling, it’s written in Ruby. Some people use it in a RubyOnRails environment. I’ve seen people having trouble with ActiveRecord connections and the scheduler. The last instance of that was with Jim.

My initial reaction was “the rufus-scheduler has nothing to do with ActiveRecord’s connection management, it’s a dumb ruby library, why do you post that here ?”, but I didn’t word that reaction and I simply pointed at the ‘connection management’ issue. That paid well, since Jim came up with a solution, closing the connection at the end of each of scheduled job (ActiveRecord was implicitely opening a new connection for the job).

One of the great things with Ruby and Open Source is that you can look at the source. So I glanced at how ActiveRecord does the connection management and learnt a thing or two. (And with Ruby there is far less code to scan before reaching the objective)

The rufus-scheduler has one thread for the scheduling and then one thread for each job it triggers. One thread per job so that the scheduling thread doesn’t get blocked by the job executions. In its “thread safe” mode, ActiveRecord stores its database connections in a hash whose key is the current Thread object_id. So if you have lots of job that do business with ActiveRecord, you’ll have lots of threads and a[n open] connection for each of those threads.

Thanks to Jim for triggering this little active_record study and for sharing his solution.

Know thyself (and your tools).I ha