Subject | Re: [Firebird-Architect] WAL and JOURNAL |
---|---|
Author | Olivier Mascia |
Post date | 2004-01-21T16:15:16Z |
Dear,
On Wed, 21 Jan 2004 09:08:36 -0500,
Leyne, Sean wrote :
be read-only beasts : only accepting read-only transactions or another
mechanism to guarantee those slaves are read-only ?
Are we sure those uncommitted changes eventually physically present on
the slave pages could not interact badly with running queries ?
If I start a "long-running" query in a default read-only transaction
(concurrency) on a slave, and new page updates come in from master
with new committed transactions, how this will work ? I should need to
see the old records that might well not exists anymore in the recent
pages. I'm not sure I'm not lost in the thing, but I fear some issue
here.
--
Best Regards,
Olivier Mascia
On Wed, 21 Jan 2004 09:08:36 -0500,
Leyne, Sean wrote :
> > Will it be easy to send set of pages to the remotes such as onlySo we're clear about the fact that those slave would be guaranteed to
> > committed transactions are reflected in the remotes ?
>
> Yes, the net effect will be that the remote/slave databases will only
> "see" committed transactions, even though the disk pages may have
> uncommitted changed.
be read-only beasts : only accepting read-only transactions or another
mechanism to guarantee those slaves are read-only ?
Are we sure those uncommitted changes eventually physically present on
the slave pages could not interact badly with running queries ?
If I start a "long-running" query in a default read-only transaction
(concurrency) on a slave, and new page updates come in from master
with new committed transactions, how this will work ? I should need to
see the old records that might well not exists anymore in the recent
pages. I'm not sure I'm not lost in the thing, but I fear some issue
here.
--
Best Regards,
Olivier Mascia