Re: Concurrency in an RDB

From: David <davidbl_at_iinet.net.au>
Date: 15 Dec 2006 05:09:40 -0800
Message-ID: <1166188180.469853.133890_at_l12g2000cwl.googlegroups.com>


Marshall wrote:
> 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.

I appreciate you making an effort.

Please note that my original intention of posting was not to convince anyone to embrace a somewhat speculative approach. My original post didn't even mention Operational Transform. Rather my intention has been to learn from people with more experience in using an RDB - specifically about whether or in what circumstances it is possible, from an application modelling perspective, to limit all mutative transactions to be fine grained and "non-algorithmic". I still haven't received more than a yes/no answer. Can someone please elaborate on that?

As it turns out I've made significant progress in the OT approach - and I believe the case is compelling. My solution is fast, simple, very efficient and highly scalable. I haven't published any of these results and I don't mind (nor am I surprised) if you don't believe me.

If you think the prior work proves me wrong then please summarise the argument or cite the relevant material. Don't be like Bob and reference an entire book. That is rude and makes me wonder whether Bob actually has a specific argument at all.

If you merely believe I'm wrong (but can't articulate it) then you have nothing concrete to say! Why say it?

[snip]

Cheers,
David Received on Fri Dec 15 2006 - 14:09:40 CET

Original text of this message