Some interesting criticisms of rails

ruby-talk
1

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

2

I for one am _not_ going to listen to the criticism of someone who is too
lazy too write it all down.
Written text I can skim, reread and think about. Spoken text is much too
linear, and also often quite hard to follow for non native speakers.

Han

···

On 9/16/05, David Balick <davidbalick@gtakethisoutmail.com> wrote:

may be found in the podcast
http://www.drunkandretired.com/2005/06/drunkandretired-podcast-episode-
09.html.

3

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.

Since each request is handled in isolation, you rarely encounter
situations where object changes ripple through with tons of
consequences. At the end of each request, you'll have to persist your
data somehow, so whether that's in a database, Madeleine store, or web
service call, I don't see that being all that different.

Perhaps these guys are just solving different problems. But I found
the rant to be very abstract and hard to relate to. If you can come up
with a concrete example, I'd love to give a more concrete answer to
these concerns.

···

--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.backpackit.com -- Personal information manager
http://www.rubyonrails.com -- Web-application framework

4

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

···

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

5

Han Holl <han.holl@gmail.com> wrote in
news:7348fe7105091612471da0abc7@mail.gmail.com:

···

On 9/16/05, David Balick <davidbalick@gtakethisoutmail.com> wrote:

may be found in the podcast
http://www.drunkandretired.com/2005/06/drunkandretired-podcast-episode
- 09.html.

I for one am _not_ going to listen to the criticism of someone who is
too lazy too write it all down.

------=_Part_9165_9483166.1126900052081--

Well... they are drunk and retired!

6

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.

I remember that from a recent Operating Systems class. So it's still
in use today.

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.

I should've brought that up to the professor. :frowning:

···

On 9/16/05, Zed A. Shaw <zedshaw@zedshaw.com> wrote:

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
>
>

7

First of all it's five philosophers (i.e. as far as I remeber it's important that the number of resource aquisitors is odd). Then of course this just serves as an illustrating example. The problem of shared resource access is all too common in CS (for example in databases). You cannot solve it by introducing a centralized server because that creates a bottleneck which defies the purpose of parallel processing. Your waiter is not the best solution. If you're interested in more details about how for example RDBMS solve this there's a lot of resources out there to read on.

I don't know why think you have to rant about real CS problems or communists. This is not an excercise to plague students but it's a real issue and an important problem which must be solved. Without real solutions your OS would likely perform much worse than it actually does.

Regards

    robert

···

Zed A. Shaw <zedshaw@zedshaw.com> wrote:

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.

8

A matter of preference perhaps. But I've tried a couple of podcasts with Chet
Hendrickson and it takes more time to get a 'cast ready for publication than to
get an article ready, and it's much less enjoyable work.

So I'd suggest that laziness isn't why people record things.

···

On Sat, 17 Sep 2005 04:47:34 +0900, Han Holl <han.holl@gmail.com> wrote:

I for one am _not_ going to listen to the criticism of someone who is too
lazy too write it all down.
Written text I can skim, reread and think about. Spoken text is much too
linear, and also often quite hard to follow for non native speakers.

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

9

Hi,

I'm kind of interested in hearing opinions relating to the original question.

I don't know a lot about Rails but I am very interested in learning more. I've mucked about with it a bit but nothing serious. I definitely formed a good impression of it.

David Balick <davidbalick@gtakethisoutmail.com> provided a URL <http://www.drunkandretired.com/2005/06/drunkandretired-podcast-episode-09.html&gt; to a podcast that contains some criticism of Rails (and almost as much praise, so I don't think of this as some kind of rant/trashing of Rails).

It is, I think, difficult to pull the argument out of the podcast. David took a shot at it...

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.

In my opinion the comments regarding extended transactions is a bit of a red herring -- it may well be an issue, but I don't know how big in practice (though I'm sure BEA, MS, and IBM want you to believe it is a HUGE problem :-). But more importantly, it seemed to obscure the real point that was expressed before that.

Here is my take on the argument made:

1) They are talking about what they call 'enterprise' applications. I think that they're talking about a class of applications that do things that are more complex than manipulating data in a database (and I think they are including in this wide-spread changes in the database in a single transaction). I think getting hung up on the term 'enterprise' is not a good idea -- everyone can name plenty of enterprise applications that primarily manipulate localised data in a database.

2) Rails encourages (forces?) the object layer and data layer to merge with some negative consequences for that class of applications (actually they may not have qualified this and so might have expressed it as a universally Bad Thing)

3) Rails does not keep track of instances; so that if two requests are made for the same object two different copies are returned (and what comes with this is a performance question)

4) Rails returns the whole object graph with each request (which in certain kinds of applications could pull much more information from the DB than necessary)

5) Rails does not provide a transaction that can contain more than one object retrieval and/or/? write to the DB (at least this is what I think they meant) and that there is too much work (knowledge maybe?) required to save changes -- this may be related to the kind of thing Hal Fulton was getting at in the recent KirbyBase thread.

Now *I* am not making these claims, all *I* am trying to do is explain what I heard on the podcast (and it isn't easy), and I don't claim that I got *their* arguments correct either. But maybe there is enough there to talk about. If not, maybe we should just make up our own straw-man issues.

Since each request is handled in isolation,

I'm not sure what you mean by this.

you rarely encounter
situations where object changes ripple through with tons of
consequences.

Do you mean that you rarely encounter situations where many objects are changed? Rarely as in not in most applications? or Rarely as in many applications but only occasionally occurring?

At the end of each request, you'll have to persist your
data somehow, so whether that's in a database, Madeleine store, or web
service call, I don't see that being all that different.

I think they are complaining about what you have to do to accomplish this in Rails, with the implication that you have to do a lot.

Perhaps these guys are just solving different problems.

Probably (and they called them 'enterprise applications' which I've already suggested is a really poor name for them, and possibly inflammatory). How would you characterise the problems that Rails is really good at, and where it is OK, and where it isn't so OK?

But I found
the rant to be very abstract and hard to relate to. If you can come up
with a concrete example, I'd love to give a more concrete answer to
these concerns.

I find the argument a bit slippery, especially as I try to write it down :slight_smile:

I agree that this would be the best thing. I don't think I understand their complaint sufficiently to try. I think I know what kind of application they are talking about, and I have a lot of experience with them, so with a bit more clarification, I might be willing to try.

(I don't think I've ever equivocated so many times in one sitting before :slight_smile:

Cheers,
Bob

···

On Sep 16, 2005, at 6:43 PM, David Heinemeier Hansson wrote:

On 9/16/05, David Balick <davidbalick@gtakethisoutmail.com> wrote:

--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.backpackit.com -- Personal information manager
http://www.rubyonrails.com -- Web-application framework

----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/&gt;
Recursive Design Inc. -- <http://www.recursive.ca/&gt;
Raconteur -- <http://www.raconteur.info/&gt;

10

Not only five philosophers, but five forks too.

The solutions here are very much about moving the complexity out of
the application and into the database, which is fine if your database
can handle it. It doesn't *remove* the complexity as such, it just
means that you can stop worrying about it until your database servers
die, which in your average web app probably won't happen.

Douglas

···

2005/9/17, Robert Klemme <bob.news@gmx.net>:

First of all it's five philosophers (i.e. as far as I remeber it's important
that the number of resource aquisitors is odd).

11

Robert, where's the logical proof that distributed locking to control access to a shared resource is always faster than using a centralized server? I'm curious if one exists.

···

On Sat, 17 Sep 2005 18:51:35 +0900 "Robert Klemme" <bob.news@gmx.net> wrote:

Zed A. Shaw <zedshaw@zedshaw.com> wrote:
First of all it's five philosophers (i.e. as far as I remeber it's important
that the number of resource aquisitors is odd). Then of course this just
serves as an illustrating example. The problem of shared resource access is
all too common in CS (for example in databases). You cannot solve it by
introducing a centralized server because that creates a bottleneck which
defies the purpose of parallel processing. Your waiter is not the best
solution. If you're interested in more details about how for example RDBMS
solve this there's a lot of resources out there to read on.

I don't know why think you have to rant about real CS problems or
communists. This is not an excercise to plague students but it's a real
issue and an important problem which must be solved. Without real solutions
your OS would likely perform much worse than it actually does.

Regards

    robert

12

Just replying for "fun", iirc, when I went to school it didn't make any
difference whether the number was odd or even--there was one fork for each
philosopher but he could only eat if he had two forks. (Sounds odd, now.)

But +1 on everything else in your post.

regards,
Randy Kramer

···

On Saturday 17 September 2005 05:51 am, Robert Klemme wrote:

First of all it's five philosophers (i.e. as far as I remeber it's
important that the number of resource aquisitors is odd). Then of course
this just serves as an illustrating example. The problem of shared
resource access is all too common in CS (for example in databases). You
cannot solve it by introducing a centralized server because that creates a
bottleneck which defies the purpose of parallel processing. Your waiter is
not the best solution. If you're interested in more details about how for
example RDBMS solve this there's a lot of resources out there to read on.

13

Bob Hutchison wrote:

Hi,

I'm kind of interested in hearing opinions relating to the original question.

Same here. I listened to the recording this morning while out running.

I don't know a lot about Rails but I am very interested in learning more. I've mucked about with it a bit but nothing serious. I definitely formed a good impression of it.

David Balick <davidbalick@gtakethisoutmail.com> provided a URL <http://www.drunkandretired.com/2005/06/drunkandretired-podcast- episode-09.html> to a podcast that contains some criticism of Rails (and almost as much praise, so I don't think of this as some kind of rant/trashing of Rails).

It is, I think, difficult to pull the argument out of the podcast. David took a shot at it...

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.

In my opinion the comments regarding extended transactions is a bit of a red herring -- it may well be an issue, but I don't know how big in practice (though I'm sure BEA, MS, and IBM want you to believe it is a HUGE problem :-). But more importantly, it seemed to obscure the real point that was expressed before that.

I got the sense that the lack of transactions was the main concern; that there was no inherent way to assure that all clients were dealing with the "same" object at any given time, and that one could not easily update multiple resources (databases, message queues, what have you) in one transactional shot.

Here is my take on the argument made:

1) They are talking about what they call 'enterprise' applications. I think that they're talking about a class of applications that do things that are more complex than manipulating data in a database (and I think they are including in this wide-spread changes in the database in a single transaction). I think getting hung up on the term 'enterprise' is not a good idea -- everyone can name plenty of enterprise applications that primarily manipulate localised data in a database.

Quite true. I sort of sniggered when they were talking about "enterprise" apps, but I also think I understood well enough what they were saying. It's sort of like when people toss around the equally vacuous term "Web 2.0"; a bit of reading between the lines often reveals the actual meaning in the given context (and it's typically less grand than one might first think).

2) Rails encourages (forces?) the object layer and data layer to merge with some negative consequences for that class of applications (actually they may not have qualified this and so might have expressed it as a universally Bad Thing)

3) Rails does not keep track of instances; so that if two requests are made for the same object two different copies are returned (and what comes with this is a performance question)

4) Rails returns the whole object graph with each request (which in certain kinds of applications could pull much more information from the DB than necessary)

5) Rails does not provide a transaction that can contain more than one object retrieval and/or/? write to the DB (at least this is what I think they meant) and that there is too much work (knowledge maybe?) required to save changes -- this may be related to the kind of thing Hal Fulton was getting at in the recent KirbyBase thread.

Now *I* am not making these claims, all *I* am trying to do is explain what I heard on the podcast (and it isn't easy), and I don't claim that I got *their* arguments correct either. But maybe there is enough there to talk about. If not, maybe we should just make up our own straw-man issues.

That sounds about right, though.

Since each request is handled in isolation,

I'm not sure what you mean by this.

you rarely encounter
situations where object changes ripple through with tons of
consequences.

Do you mean that you rarely encounter situations where many objects are changed? Rarely as in not in most applications? or Rarely as in many applications but only occasionally occurring?

At the end of each request, you'll have to persist your
data somehow, so whether that's in a database, Madeleine store, or web
service call, I don't see that being all that different.

I think they are complaining about what you have to do to accomplish this in Rails, with the implication that you have to do a lot.

Perhaps these guys are just solving different problems.

Probably (and they called them 'enterprise applications' which I've already suggested is a really poor name for them, and possibly inflammatory). How would you characterise the problems that Rails is really good at, and where it is OK, and where it isn't so OK?

But I found
the rant to be very abstract and hard to relate to. If you can come up
with a concrete example, I'd love to give a more concrete answer to
these concerns.

I find the argument a bit slippery, especially as I try to write it down :slight_smile:

But still, not really a rant; while these guys may have been a bit obtuse in explaining their concerns, they seem to have reasonable questions.

James

···

On Sep 16, 2005, at 6:43 PM, David Heinemeier Hansson wrote:

On 9/16/05, David Balick <davidbalick@gtakethisoutmail.com> wrote:

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

14

That's assuming that's all we do: web apps that can move all the login
to the database.

15

First of all it's five philosophers (i.e. as far as I remeber it's
important that the number of resource aquisitors is odd).

[snip]

Just replying for "fun", iirc, when I went to school it didn't make any
difference whether the number was odd or even--there was one fork for each
philosopher but he could only eat if he had two forks. (Sounds odd, now.)

When I first learned of the Dining Philosophers, they used chopsticks so
it made sense that they would need two in order to eat.

···

On Sat, September 17, 2005 4:15 pm, Randy Kramer said:

On Saturday 17 September 2005 05:51 am, Robert Klemme wrote:

--
Jason Voegele
"There is an essential core at the center of each man and woman that
remains unaltered no matter how life's externals may be transformed
or recombined. But it's smaller than we think."
    -- Gene Wolfe, The Book of the Long Sun

16

Bob Hutchison wrote:

Hi,
I'm kind of interested in hearing opinions relating to the original question.

Same here. I listened to the recording this morning while out running.

I don't know a lot about Rails but I am very interested in learning more. I've mucked about with it a bit but nothing serious. I definitely formed a good impression of it.
David Balick <davidbalick@gtakethisoutmail.com> provided a URL <http://www.drunkandretired.com/2005/06/drunkandretired-podcast- episode-09.html> to a podcast that contains some criticism of Rails (and almost as much praise, so I don't think of this as some kind of rant/trashing of Rails).
It is, I think, difficult to pull the argument out of the podcast. David took a shot at it...

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.

In my opinion the comments regarding extended transactions is a bit of a red herring -- it may well be an issue, but I don't know how big in practice (though I'm sure BEA, MS, and IBM want you to believe it is a HUGE problem :-). But more importantly, it seemed to obscure the real point that was expressed before that.

I got the sense that the lack of transactions was the main concern; that there was no inherent way to assure that all clients were dealing with the "same" object at any given time, and that one could not easily update multiple resources (databases, message queues, what have you) in one transactional shot.

Yes I agree, but there are two levels of this that came up -- at least I think so. The first, and the one that I think they were most concerned with, seemed to be transactions at the application level but that only concerned the db. The second was the extended transactions that include all kinds of stuff beyond the db (as you say, like message queues, and any number of other things like workflow, distributed transactions and stuff like that). If Rails cannot deal with transactions as the application level then it surely can't deal with the extended transactions. As I said, I don't know Rails that well (cursory understanding, at best really) -- does Rails really not have application level transactions? By application level transactions I understand that to mean that if the application pulls a bunch of objects in from the database, modifies some of them, then Rails can guarantee that all of the changed objects have been written successfully or not at all to the db. If Rails cannot do this, then there is a class of applications that Rails cannot support. I find this difficult to believe.

Here is my take on the argument made:
1) They are talking about what they call 'enterprise' applications. I think that they're talking about a class of applications that do things that are more complex than manipulating data in a database (and I think they are including in this wide-spread changes in the database in a single transaction). I think getting hung up on the term 'enterprise' is not a good idea -- everyone can name plenty of enterprise applications that primarily manipulate localised data in a database.

Quite true. I sort of sniggered when they were talking about "enterprise" apps, but I also think I understood well enough what they were saying. It's sort of like when people toss around the equally vacuous term "Web 2.0"; a bit of reading between the lines often reveals the actual meaning in the given context (and it's typically less grand than one might first think).

2) Rails encourages (forces?) the object layer and data layer to merge with some negative consequences for that class of applications (actually they may not have qualified this and so might have expressed it as a universally Bad Thing)
3) Rails does not keep track of instances; so that if two requests are made for the same object two different copies are returned (and what comes with this is a performance question)

And, of course, raises the possibility of a data integrity concern.

4) Rails returns the whole object graph with each request (which in certain kinds of applications could pull much more information from the DB than necessary)
5) Rails does not provide a transaction that can contain more than one object retrieval and/or/? write to the DB (at least this is what I think they meant) and that there is too much work (knowledge maybe?) required to save changes -- this may be related to the kind of thing Hal Fulton was getting at in the recent KirbyBase thread.
Now *I* am not making these claims, all *I* am trying to do is explain what I heard on the podcast (and it isn't easy), and I don't claim that I got *their* arguments correct either. But maybe there is enough there to talk about. If not, maybe we should just make up our own straw-man issues.

That sounds about right, though.

So we have a start :slight_smile:

···

On Sep 19, 2005, at 7:14 PM, James Britt wrote:

On Sep 16, 2005, at 6:43 PM, David Heinemeier Hansson wrote:

On 9/16/05, David Balick <davidbalick@gtakethisoutmail.com> wrote:

Since each request is handled in isolation,

I'm not sure what you mean by this.

you rarely encounter
situations where object changes ripple through with tons of
consequences.

Do you mean that you rarely encounter situations where many objects are changed? Rarely as in not in most applications? or Rarely as in many applications but only occasionally occurring?

At the end of each request, you'll have to persist your
data somehow, so whether that's in a database, Madeleine store, or web
service call, I don't see that being all that different.

I think they are complaining about what you have to do to accomplish this in Rails, with the implication that you have to do a lot.

Perhaps these guys are just solving different problems.

Probably (and they called them 'enterprise applications' which I've already suggested is a really poor name for them, and possibly inflammatory). How would you characterise the problems that Rails is really good at, and where it is OK, and where it isn't so OK?

But I found
the rant to be very abstract and hard to relate to. If you can come up
with a concrete example, I'd love to give a more concrete answer to
these concerns.

I find the argument a bit slippery, especially as I try to write it down :slight_smile:

But still, not really a rant; while these guys may have been a bit obtuse in explaining their concerns, they seem to have reasonable questions.

James

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/&gt;
Recursive Design Inc. -- <http://www.recursive.ca/&gt;
Raconteur -- <http://www.raconteur.info/&gt;

17

Thanks, that makes more sense and rings a bell!

regards,
Randy Kramer

···

On Sunday 18 September 2005 06:09 am, Jason Voegele wrote:

When I first learned of the Dining Philosophers, they used chopsticks so
it made sense that they would need two in order to eat.

18

Well, I first heard of the dining philosophers in the Java tutorial
where it serves as a perfect example to ilustrate deadlocks:
http://java.sun.com/docs/books/tutorial/essential/threads/deadlock.html

19

Rails can certainly do simple transactions. You just pass a block to
the 'transaction' method and all database writes within it will be
within a single transaction.

What may be more difficult is maintaining a single transaction across
multiple http requests. I think you'd need to store the modified
objects within the session until you were ready to do one big commit
to the database.

···

On Tue, Sep 20, 2005 at 12:38:22PM +0900, Bob Hutchison wrote:

does Rails really not have application level transactions? By
application level transactions I understand that to mean that if the
application pulls a bunch of objects in from the database, modifies
some of them, then Rails can guarantee that all of the changed
objects have been written successfully or not at all to the db. If
Rails cannot do this, then there is a class of applications that
Rails cannot support. I find this difficult to believe.

20

To be a little rude (but with a helpful intent), you don't have to know any rails to be able to type "rails transactions" into Google and look at the first 1-5 hits to decide that it does in fact have transactions, and not just on a per-table basis.

···

On Sep 19, 2005, at 9:38 PM, Bob Hutchison wrote:

As I said, I don't know Rails that well (cursory understanding, at best really) -- does Rails really not have application level transactions? By application level transactions I understand that to mean that if the application pulls a bunch of objects in from the database, modifies some of them, then Rails can guarantee that all of the changed objects have been written successfully or not at all to the db. If Rails cannot do this, then there is a class of applications that Rails cannot support. I find this difficult to believe.