On Wednesday 03 December 2003 11:13, Chris Travers wrote:
> Comments inline
>
> From: "Jan Wieck" <JanWieck@Yahoo.com>:
> > There are many problems with a "proxy" solution. One is that you really
> > don't know if a statement does modify the database or not. A SELECT for
> > example can call a user defined function somewhere and that can do
> > whatever the programmer likes it to do. So you would have to "replicate"
> > all that too. Granted, you can exclude this type of database usage from
> > your supported list.
>
> That is why it would be nice to be able to check for altered tuples on a
> select before deciding whether to replicate... In this case you could have
> a query->check for altered tuples-> if altered replicate query routine.
>
> > Next you don't have control over sequence allocation. Every application
> > that uses sequence allocated ID's is in danger, because they are not
> > blocking, you cannot force the order of assignments and they don't roll
> > back either.
>
> This is the more serious problem. I will have to think this one over. I
> wonder about having cross-proxy sequence generators.
Don't forget you need to lockstep system-clocks too, otherwise SELECT * FROM
log_stats WHERE log_ts > now() - '1 hour' becomes ill-defined.
Hmm - thinking about it, you'll need to serialise queries too. Otherwise you
could issue simultaneous queries to machines A,B and have A complete in order
(1,2) and B in order (2,1). I don't see a way around that one without a
guaranteed scheduling order at the kernel level.
--
Richard Huxton
Archonet Ltd