Re: Concurrency in an RDB

Marshall wrote:
> On Dec 20, 2:15 am, "David" <davi..._at_iinet.net.au> wrote:
> > 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.
>
> No they weren't. They were handwavy descriptions of something
> one could build that you claim used some of the techniques
> you're proposing. *I* haven't seen anything yet except vague
> descriptions.
>
> You do know this *is* a theory group, right? Do you actually
> have any theory? Any papers? Any math? Computational
> models? Equations? Examples, even?

Yes, I have all that, including formal proofs of correctness. I have no intention of describing the detail in this NG even though I expect it could interest you. In any case it is irrelevant to the original post.

> > > 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.
>
> By "a total ordering on site identifiers" I take it you mean
> that every peer gets an id, and if updates from id1 and
> id2 conflict, then id1 always wins. Terrific, as long as
> I can have id1, ha ha.

You trivially misrepresent. I made it quite clear that integrity constraints that force user edits to be discarded after merging should be avoided.

> > 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.
>
> Okay, I think you're in the wrong newsgroup. This is a database
> theory newsgroup. Those with an application framework du jour
> are directed to comp.object. OT is OT here.

The approach I have described addresses the goals of a DBMS, such as atomicity, integrity and multi-user support. It seems relevant to this NG.

I think your problem is that I haven't provided the mathematical detail to justify my claims. I agree that my descriptions are more about the repercussions of OT for a DBMS rather than revealing how it works in sufficient detail to be persuasive.

Cheers,
David Received on Thu Dec 21 2006 - 02:14:44 CET