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.
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:
Poll.transaction{ lock!; increment!(:results_counter); }
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.