3 ms·
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 fo
by bradgessler 18y ago
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.
- swombat 18y agoThat's irrelevant to the discussion at hand - if anything, it goes to show that parallelism is already integrated into the rails architecture via transactions.
- crabapple 18y agoyou should stop posting until you take classes in operating systems and compilers. really
- bradgessler 18y agoIts 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: 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.
- newt0311 18y agoSince when does a decent database lock tables for concurrent transactions?