Re: Concurrency in an RDB

From: David <davidbl_at_iinet.net.au>
Date: 20 Dec 2006 02:15:58 -0800
Message-ID: <1166609758.716210.216650_at_80g2000cwy.googlegroups.com>


Marshall wrote:
> On Dec 19, 11:17 pm, "David" <davi..._at_iinet.net.au> wrote:
> > Marshall wrote:
> >
> > > So, howsabout you give us an example? So far all we've heard
> > > from you has been a description of properties of your proposed
> > > solution. Please show me an example of doing something
> > > modestly nifty with OT that might not hold up so well in
> > > a distributed transaction setting.
> >
> > > Assume I'm already aware that network cards, switches,
> > > and whole machines periodically misbehave. (Oh, how
> > > I wish I was *less* aware of that.)
> >
> > Real time, interactive editing of replicated data is very well suited
> > to OT.
>
> This is nothing but more description; you have already supplied
> plenty of that. My interest is in an example.

The shared jigsaw, text and white board components were real examples that I gave.

> I have two clients, C1 and C2. I have a table T in a distributed,
> replicated dbms. The table exists on both server S1 and S2.
> T has a constraint that "count(*) <= 1" and is currently empty.
>
> C1 issues an insert into T of value (5). C2 issues an insert
> into T of value (7). S1 receives C1's insert first, and C2 receives
> S2's insert first. What happens? S1 does what? S2 does
> what?

It is certainly possible for the system to impose your constraint, but in that case you will find that it arbitrarily throws away records so that only one remains. Both sites will agree on the record that was kept. The symmetry is broken using a total ordering on site identifiers.

This is even true if there were many sites that independently inserted a record. At quiescence all sites will agree on the single remaining record in the table, irrespective of the order in which they connect and exchange operations. There is no central server that makes the decision.

However, integrity constraints should be weak enough to support merging of updates without a tendency to simply throw away user edits (by annulling conflicting operations). In your example it is better to allow the table to have any number of records in the DB, and independently "calculate" when the DB is currently in a valid state.

That way, when the constraint is broken (after merging) 1. the fact that a conflict occurred is made clear to the users (preferably without an annoying modal dialog) 2. the users can choose which record(s) they want to delete in order to satisfy the integrity constraint

So weak (and simple) integrity constraints helps to achieve fast, fine-grained transactions, and allows for highlighting merge conflicts and avoids silently discarding user's work.

Ideally the editing environment highlights things that are invalid, rather like some source code IDEs that highlights syntax errors in red.

A form for editing a record in a database could display fields in red that are in an invalid state.

Another example is a text field with a constraint on the maximum size of the field. This is incompatible with silently merging user edits because the merged result can break the constraint even though no individual user broke the constraint while locally editing the text.

OT can certainly enforce such a constraint if you want it. I'm just saying that it's not a good idea in practice.

An edit box with a constraint on the size of the string (never mind a more complex constraint) can be a pain in the arse. For example, what happens if you want to paste in some text that would temporarily make the string too big? Will the paste operation be prohibited? Do you have to launch you favorite text editor just to edit the string before it can be pasted into the edit box?

I like the idea that things turn red when they're in an invalid state. I don't like modal dialogs that pop up telling me that my data entry was bad, or the idea that my edits are only transient until I'm ready to commit them by clicking OK on a dialog.

Please note finally that I haven't yet examined in any great deal whether OT is really appropriate for relational data.

> An *example* please. Not a description. Not requirements,
> or praise, or claims about how transactions ought to be
> sized, or any of that stuff. An illustrative example.
>
> Impress me.

Cheers,
David Received on Wed Dec 20 2006 - 11:15:58 CET

Original text of this message