Re: Concurrency in an RDB

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?

> > 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.

> 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.

Marshall Received on Wed Dec 20 2006 - 22:10:50 CET