Re: Concurrency in an RDB

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

Didn't David already address this? He wrote, "Nevertheless it is possible that the merge has broken higher level semantic constraints that can't be validated by the system. For that reason, after a merge there is always the responsibility of validation before committing."

I'm confused as to why you have clients and servers in your exmaple. The description David gave of his system was peer to peer.

In your example, there would be two records in the table the constraint that "count(*) <= 1" can not be guaranteed at quiescence. In earlier posts it was discussed that such constraints can not be enforced under OT.

Dan Received on Wed Dec 20 2006 - 10:25:50 CET