Re: Concurrency in an RDB

On Dec 20, 5:14 pm, "David" <davi..._at_iinet.net.au> wrote:
> Marshall wrote:
>
> > 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.

Okay.

However I should tell you that I have a formal proof that your approach is invalid. I have shown it to several university professors, (I can't say who) and they all agree it is sound. However I am unable to reveal the proof, for reasons that I prefer not to specify.

See what I did there?

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

You complain that I misrepresent but you don't correct the supposed misrepresentation. If I didn't read your mind correctly in expanding the phrase "total ordering on site identifiers" then what did you mean? But I recall that you have "no intention of describing the detail[s]."

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

I see: your approach is to limit what constraints are allowed. Do you see why this might not be appealing for a general purpose data management solution?

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

Addresses them ... how exactly? You address atomicity and integrity by forbidding or severely restricting them, basically. If I understand you correctly (entirely possible I don't, since you're so spartan on specifics)
then client code can't even count on successful updates persisting.

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

Well, a number of us have said that those repercussions are severe enough to rule out this approach for general purpose use.

I'm unclear as to your goals for this thread. You've made it clear that you don't want to get into details; okay. If you wanted to provide us with a high-level description of some ideas you have, you've done that. If it was to get us to agree that the limitations you're proposing aren't too bad, we've declined to do that. What else would you like to discuss?

Marshall Received on Thu Dec 21 2006 - 02:54:41 CET