From: Daniel Sheppard <daniels@...>
Date: 2005-09-20T13:08:03+09:00
Subject: Re: Some interesting criticisms of rails [NOT dining philosophers]

Rails (well, we're really talking activerecord) performs transactions
fine
(http://api.rubyonrails.com/classes/ActiveRecord/Transactions/ClassMetho
ds.html). If you're pulling a bunch of objects out of the database and
modifying them all atomically, Rails will say "bring it on". If you're
pulling a bunch of objects out of DIFFERENT databases, you can sort of
do this with rails (see the linked docs), but it's not an ideal solution
and it's not going to be 100% reliable (if the commit message is sent to
database1 and the system gets killed before the commit gets sent to
database2, you've got data that's out of sync).

But that doesn't mean you can use rails in situations where some monster
multiple-database + coffee machine + door lock + lighting rig system
needs to be changed atomically. You just figure out how to do so
reliably in whatever way makes sense in whatever language makes, expose
it as a service (webservice, socket service, whatever) and have rails
put out a call to that.

The problem of distributed transactions is REALLY HARD. Hell,
non-distributed transactions aren't exactly a piece of cake. That's why
Rails lets the database handle it, because that's the database's job. If
you've got something that can handle distributed transactions - GREAT -
use the damn thing, and let Rails do its job of parsing requests and
pumping out pages.


-----Original Message-----
From: Bob Hutchison [mailto:hutch@recursive.ca] 
Sent: Tuesday, 20 September 2005 1:38 PM
To: ruby-talk ML
Cc: Bob Hutchison
Subject: Re: Some interesting criticisms of rails [NOT dining
philosophers]

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


#####################################################################################
This email has been scanned by MailMarshal, an email content filter.
#####################################################################################