Re: Concurrency in an RDB

From: David <davidbl_at_iinet.net.au>
Date: 21 Dec 2006 17:52:07 -0800
Message-ID: <1166752327.401320.320920_at_42g2000cwt.googlegroups.com>


Marshall wrote:
> On Dec 21, 3:08 pm, "David" <davi..._at_iinet.net.au> wrote:
> > Marshall wrote:
> > > So he wrote a couple of apps. Woo hoo. And he's told us, in
> > > the most excruciatingly high level, handwavy manner possible,
> > > that they have this and that awesome property.
> > Your sarcasm doesn't do you credit.
>
> Mmmm, "sarcasm" isn't quite right. "Woo hoo" was dismissive
> but not particularly harsh. Nor was any irony present. Without
> at least one and preferably both qualities, it doesn't qualify
> as sarcasm. On the other hand "dismissive" is too soft.
> Le bon mot eludes me at the moment.
>
>
> > > But he hasn't
> > > told us anything about specifics. The system "achieve[s] intention
> > > preservation, causality preservation and of course convergence
> > > at quiescence." Also, "remote edits are incorporated
> > > asynchronously after undergoing transformation."
> > > The actual details of how any of this is accomplished
> > > are somehow omitted.
> >
> > ... omitted because the basic ideas are
> > covered in the literature. For example
> >
> > "Achieving convergence, causality-preservation, and
> > intention-preservation in real-time cooperative editing systems," C.
> > Sun, X. Jia, Y. Zhang, Y. Yang, D. Chen.
>
> Thank you for the reference.
>
>
> > As I've said before, the details about how OT works is not the subject
> > of this thread. It is more about the repercussions of using OT in a
> > DBMS.
>
> Just looking at the basics, I don't see how it would be possible to
> use this for a DBMS. DBMSs are useful because of the properties
> they guarantee, and it strikes me that the most fundamental such
> property is durability: when I commit, I can count on it sticking.

Why is that so important? Assuming there is no atomicity requirement that encompasses systems or processes external to the DB, what's wrong with only flushing transactions every 500msec (say)? Surely you're not concerned with losing the last half a second of work before the power failed? Aren't you really more concerned about atomicity and integrity?

> Also very important: integrity enforcement. It appears you want
> to restrict what integrity constraints can be enforced centrally.
> That's not very appealing.

You haven't commented on my claim that systems using OT could support extremely complex integrity constraints, through separate data validation queries.

> For some restricted set of applications where durability
> most-of-the-time is good enough, and integrity constraints
> are few, it might be useful. Collaborative editing seems
> like a good fit. Not source code control or anything that
> handles money, though.

I agree that financial systems need all the conventional ACID properties, including durability. When an ATM hands out cash, it is vital (for the bank) that the transaction be durable. Another example is an airplane reservation system where there is a real seat on a real plane so therefore seats need to be allocated from the DB with pessimistic locking. I discussed this with Sampo, and brought up the idea of the difference between "data" and "device".

However I can think of lots of DB applications where divergence at different sites is fair and reasonable (and even desirable).

OT is perfectly suited for a source code repository. Do you use a source code repository like CVS or Subversion that uses branching and merging, and allows developers to edit the same files concurrently?

Cheers,
David Received on Fri Dec 22 2006 - 02:52:07 CET

Original text of this message