Berabrd,
Shadowing is not under two phase commit operation. There are no trasnactions
in progress. It merely duplicates the disk write operation.

Alan

> -----Original Message-----
> From: Bernard Devlin [mailto:knowledgeworks@...]
> Sent: Sunday, 6 July 2003 9:51 PM
> To: firebird-support@yahoogroups.com
> Subject: [firebird-support] Re: Ramdrive
>
>
> Thanks Philip, those are interesting thoughts.
>
> It would seem to me that a) is not so important (OK... one might lose
> the speed advantage if the sort file was also being held in
> persistent storage). I guess it might be more of a problem if the
> ramdrive held both db & sort files, and it ran out of space...
>
> Your second point looks much more important. But I would think that
> any commit that happens at the time that a server crashes is to be
> considered questionable. For instance, if one is using asynchronous
> writes, then any data in the cache would be lost if there is a server
> crash. Obviously, if one just reset the OS gracefully (or downed the
> Firebird server process) the file system cache would be written out
> to disk.
>
> I imagine that what you are suggesting is also a potential problem
> with any two-phase commit, or with the workings of the Firebird
> shadow system per se e.g. what if both primary db and shadow are
> being held on persistent drives, and the shadow drive is slower. If
> there's a crash at commit time, then the shadow db may not be updated.
>
> Given that in my scenario on an OS reset the primary db is just not
> there any more, it is not an issue that the primary and the shadow
> are not consistent. In fact, in my scenario I think the data is
> likely to have more guarantee of consistency; the primary and the
> shadow cannot be inconsistent if the primary no longer exists.
> However, in the scenario where they are both on persistent media, and
> there is a crash before the shadow is updated, then the primary and
> shadow could be inconsistent.
>
> I'm assuming that the Firebird shadow process is nothing more than a
> two-phase commit. Hopefully, someone with more knowledge about these
> things will step in and enlighten me. This would guarantee the
> consistency of primary and shadow in all circumstances.
>
> I think maybe I've not even understood the importance of your second
> point. Please elaborate if I seem a bit dense!
>
> I forgot to mention where I found the ramdrive software (my test
> machine is running XP, but they have many variants for win32 at this
> site):
> http://www.cenatak.com
>
> My understanding is that the facilities to use ramdrive filesystems
> are built into Linux.
>
> I'd be really interested to hear if you see the same kinds of
> performance gains I mention.
>
> Regards,
> Bernard
>
>
>
> --- In firebird-support@yahoogroups.com, "unordained"
> <unordained_00@c...> wrote:
> > Bernard: random comments (i'm just a firebird user) --
> >
> > a) watch out for the sort file. i've noticed rather large files
> in /tmp/ on my linux box (hey, the
> > query wasn't done yet, okay?) and you'd want -that- in memory too,
> so unix sort can run quickly on
> > it. maybe. (assuming new versions of firebird still do this ... i'm
> lost somewhere in the past.)
> >
> > b) just hope the shadow file is required to finish committing
> entirely to disk before commit()
> > returns successfully. you'd hate to have transactions lost in lala
> land because your RAM instantly
> > said it worked, right before the machine crashed. (again, i dunno
> what i'm talking about.)
> >
>
>
>
>
> To unsubscribe from this group, send an email to:
> firebird-support-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>