I've got a big project running on MRI Ruby and Rails 3.2 on Passenger with an app that was not designed with thread-safety in mind and this app handles mailings through DelayedJob and the database is paying a heavy price for this.
Some possible problems are mentioned in the sidekiq railscast http://railscasts.com/episodes/366-sidekiq including:
- database connection limit (if using thread-pool of 1, the db connection limit should be doubled)
- thread-safety (this is probably the show stopper)
- fiber-safety? Is this an issue with AR?
So, the question are:
- how viable is it to make a big project thread-safe enough for the mail generation to work in threads inside the passenger process? (mailings are complex enough to depend on AR)
- same question when using sidekiq, "how viable is it to make a big project thread-safe enough for the mail generation to work using sidekiq? (mailings are complex enough to depend on AR)"
- apart from db connection limit and thread-safety issues, is there anything else to consider or less obvious got'chas I failed to forsee?
I think that you are mixing up some stuff here.
I never used sidekiq, but I don't think that you have to turn on
thread_safe!
in your Rails application to use it.AFAIK this is just for the request-processing to have a lock, or no lock in thread_safe! mode, so the Rails process can handle multiple requests in parallel.
When using sidekiq, that should not be one of your concerns. Just your E-Mail-Processing code needs to be thread-safe. Only the project maintainer can answer that question though.