Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: replication via tuple streams

Re: replication via tuple streams

From: Marshall <marshall.spight_at_gmail.com>
Date: 28 Mar 2007 16:20:42 -0700
Message-ID: <1175124042.191730.256340@e65g2000hsc.googlegroups.com>


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 Wed Mar 28 2007 - 18:20:42 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US