Re: Concurrency in an RDB

On Dec 12, 12:30 am, monaro..._at_gmail.com wrote:
> To all those stating that David should do some background reading - did
> you bother to look into Operational Transform (OT) as mentioned by
> David? There is potentially a whole new way of thinking about databases
> and distributed systems that should not be ignored.

I did. Google search results, in order:

1. A consulting company
2. A vendor
3. A research paper from U Waterloo (the first good sign)
4. An accounting firm mentioning it in the context of Sarbannes-Oxley

Ouch.

Let's pursue the U Waterloo link. Here's the abstract:

   The distributed operation transform (dOPT) is proposed     by Ellis and Gibbs as a lock-free algorithm to ensure the    consistency of concurrently updatable distributed objects.    dOPT is shown by counterexample to be incorrect. A    corrected algorithm is given for a restricted environment    based on point-to-point communication. There appears to    be no simple correction to dOPT for a general environment    based on broadcast communication.

This is enough to convince me that this is not worth pursuing without significant new, favorable evidence.

> Given David's area of research, perhaps his views are indeed valid and
> rather than being completely dismissive, this community should
> investigate what impact OT may have on DBMS implementations.

No, we really ought to be completely dismissive. In the absence of compelling evidence, dismissal is the best course to pursue. <xml selfreference="ironic">There is <b>so</b> much crap out there!</xml>

> I've
> heard no innovative comments here other that those made by David trying
> to link OT to distributed computing using a functional programming
> model.

"Innovative" is not by itself a goal. "Better" (or "faster" or "cheaper")
are goals. The idea that someone who admits a lack of a background with DBMSs should be listened to because what he has is "new" is unsound. There are species that fixate on shiny things, but we should do better.

> I would tend to agree with many of Davids comments that
> mutative operations are short-lived if (and only if) you are mutating
> "free" data. Any derived data should simply be marked as dirty and
> recalculated on demand - such recalculation should not be considered to
> be mutative in terms of the DBMS as it only affects application state.

Mutative operations are short-lived if you are doing simple ones. If you are doing complex, difficult ones, then they are not short-lived.

> [...] open you minds and we all may learn a thing or two.

I think the best way to open one's mind is by familiarizing oneself with the preexisting body of knowledge that a field has to offer. You can't know if what you're thinking of is better if you don't know what's being done now.

Marshall

PS. I apologize for the use of the word "preexisting." Received on Thu Dec 14 2006 - 04:16:26 CET