[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: Some interesting criticisms of rails
From:       "Zed A. Shaw" <zedshaw () zedshaw ! com>
Date:       2005-09-17 2:10:58
Message-ID: 20050916220948.337e8f2a.zedshaw () zedshaw ! com
[Download RAW message or body]


I remember reading about the Dining Philosophers problem when I was young and how it \
was solved with this incredibly complex logic proof that laid out most of the rules \
for what we know as "thread locking".  For those of you who don't know, the Dining \
Philosophers is where there's four idiots arguing about communism eating a massive \
bowl of pasta and they're too stupid to ask for more than two serving forks.  So, \
these "philosophers" spend a lot of time fighting over the forks and there needs to \
be a way to coordinate this fork "sharing".  The solution?  Ah, we'll add even more \
complexity to the problem and create neat things like semaphors.

Of course another way to solve the Dining Philosophers problem is: USE A FUCKING \
WAITER.  You see, if these idiots don't serve themselves--but instead get their pasta \
from a "server"--then you don't have anybody arguing over shared forks.  Hmmmm.  \
"Server".  I wonder why we call systems that act as a single access point to a \
service "servers"?  Gee.  That just stumps my tired little brain.

What's that got to do with the world of distributed transaction management?  Well, \
you only need to have complicated distributed locking primitives when you try to \
distribute your shared resources to the point that people have to fight over them.  \
If you just have a "server" that controls access and "share nothing" then the problem \
is solved in a much simpler way.

And BTW, if you've ever seen a gang of philisophical communists duel with forks for \
the last serving of fusili then you'll realize that letting communists share is not \
nearly as fast as having a waiter serve.

Zed A. Shaw
http://www.zedshaw.com/


On Sat, 17 Sep 2005 04:36:35 +0900
David Balick <davidbalick@gtakethisoutmail.com> wrote:

> may be found in the podcast 
> http://www.drunkandretired.com/2005/06/drunkandretired-podcast-episode-
> 09.html.
> 
> I am considering using rails (as opposed to asp.net) so am wondering what 
> y'all think of what these guys say.
> 
> In a nutshell, they say that Rails starts to get less appropriate for apps 
> with transactions that encompass entities other than just the database. If 
> the server side objects also modify the data, and particularly of the 
> modified objects then affect other objects, then it can become very non-
> trivial to handle all of that in Rails.
> 
> Any feedback on this from experienced Rails folk would be most appreciated.
> 
> Cheers,
> David Balick
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]