Throwing a few mutex around loggers and database connections is only part of the battle, there are undoubtedly plenty of race conditions with ActiveRecord since with it's lack of an identity map and optimistic locking. Beyond that, Rails requests do not operate transactionally on the db side. To perform an atomic increment on an activerecord model's column naturally (model.column += 1) and having it behave correctly is a long way from happening. Rails applications generally don't even have error handling code for cases where there is an aborted transaction due to deadlocks (an expected condition in a transactionally sound system), nevermind actually implementing it correctly to re-run the unit of work. The only reason they get away with it is that most apps running Rails don't give a damn about data consistency, and hence, don't use multi-statement transactions, and hence, don't take out many locks at once, and hence, don't deadlock.

Headius: Q/A: What Thread-safe Rails Means

I agree with this comment. It can't be easy to make Rails thread-safe.