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.

The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication.

OAuth Core 1.0

“F**KING NDA” has become a mantra on Twitter. Every time a developer posts about his or her latest run-in with the metaphorical brick wall that is Apple’s NDA, the capitalized expletive is sounded off. “F**KING NDA” has become such a phenomenon, a website has sprung up at FuckingNDA.com to track the twisted tweets.

iPhone Coders Miffed Muzzled By Apple s NDA - Webmonkey

Funny for non-iPhone developer.

Not so funny for iPhone developer.