Re:"Sequential programming is dead. So stop teaching it"
by bradgessler on Thursday November 13, 2008 @12:11PM
(#363237)
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.
[ Parent
| on HN ]
Re:"Sequential programming is dead. So stop teaching it"
by swombat on Thursday November 13, 2008 @12:14PM
(#363245)
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.
Re:"Sequential programming is dead. So stop teaching it"
by bradgessler on Thursday November 13, 2008 @01:39PM
(#363396)
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:
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.
Re:"Sequential programming is dead. So stop teaching it"
by crabapple on Thursday November 13, 2008 @12:26PM
(#363266)
you should stop posting until you take classes in operating systems and compilers. really
Re:"Sequential programming is dead. So stop teaching it"
by swombat on Thursday November 13, 2008 @03:57PM
(#363584)
You're a condescending fuckwit.