Friday, January 18, 2008
Say it ain't so: Ruby on Rails not thread-safe, no prepared statements?
Maybe everyone already knows this. But I've been hearing about Ruby on Rails for over a year now, and I know people working on it, and I am reading all this stuff about putting Ruby on Rails on Glassfish and getting it into the enterprise. I did hear some mumblings about scaling issues with Ruby on Rails. But I didn't know it was as basic as Ruby on Rails not being thread-safe.
Hm, maybe this guy got it wrong. But no, here is another post. And another.
The author of the last post, Greg Luck, says something else that just blows my mind as a database programmer - Ruby on Rails doesn't support prepared statements. Really? So I checked for other sources. Yep, it's true.
Somebody in Greg's comments said something about how Greg obviously didn't know about ActiveRecord caching. Um, that's not really the point. The point is, when you do hit the database, why on earth would you force it to recompile and re-optimize the SQL each time?
I have worked with multi-threaded applications since 1988. Multi-threading is not new. Pre-compiled SQL showed its power ofter fifteen years ago, and every database vendor worth its salt supports it. How can it be possible that an entirely new framework for server-side database applications is not thread-safe and does not support prepared statements? It's one of those things that makes one's jaw drop.
Maybe I'm just completely missing something. Maybe I'm living in the stone age. Someone explain to me where I've gone wrong. I strive to be open-minded and anyone who knows me knows I regularly change my mind if I am convinced I have it wrong.
But as it stands, if someone were to suggest to me that we should use Ruby On Rails for a web-scale server-side application, I would sit him or her down for coffee (or a strong drink), explain the limitations above, and beg them to think about this very seriously, and at the minimum, please, run some tests before committing to this framework.