Re: replication via tuple streams

On Mar 28, 2:52 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> Marshall wrote:
>
> Not sure why you mention closure, but the above reminds me that I've
> long thought replication and concurrency are just two sides of the same
> coin. Also think that much of the concurrency theory involves shell
> games or other trickery to make it hard for people to understand just
> what the problem is. Always seemed to me that replication must
> replicate all and everything unless some method is present to stop
> replication. Same goes for concurrency - when the "serialization" mode
> is entered, all previous queries need to be either re-iterated or their
> results guaranteed. For me, the key word in the latter two sentences is
> "all".

Hmmm. Interesting. I agree that much of concurrency is quite difficult and error-prone; I am not sure I agree that concurrency *theory* is the same way. (OTOH, I expect we have been looking at different theories.) To me this difficulty is clearly the result of the use of "shared-state concurrency" a la the Java thread model. *Way* too low-level.

As far as replicating "all and everything", well, that's definitely a serious issue with replicating DML. But it's not any kind of issue with replicating tuple streams; you can pick and choose exactly which tables you want and replicate no others. (In fact, with some care you could even replicate a projection of a table.)

Marshall Received on Thu Mar 29 2007 - 01:20:42 CEST