This isn't really true; you can't just start spinning up multiple mongrels with no consequence to your application. If this were true, there would be no need for locking the database in your application code for a transaction. Plus you can only spin up so many mongrels before your database performance starts to suffer.
That's irrelevant to the discussion at hand - if anything, it goes to show that parallelism is already integrated into the rails architecture via transactions.
Its not built into rails transactions; you explicitly have to lock tables/rows (depends on the db/engine you're running) inside of transactions to avoid conflicts. We ran into this problem with Poll Everywhere when we had to update a counter cache column. We had something along the lines of
Poll.transaction { increment!(:results_counter) }
This worked fine with one mongrel in our dev and test environments but when we threw that out to our cluster of mongrels, we got all sorts of locking errors when a torrent of people would vote. To resolve the issue we had to add:
If this isn't a bottleneck or leaky abstraction then I don't know what is. Locks are ugly and I consider them a hack. In our case an RDBMS probably isn't the best data store solution.
