| Subject | Re: [firebird-support] Does the shadow get updated within the transaction? |
|---|---|
| Author | unordained |
| Post date | 2004-04-28T08:33:32Z |
I thought I remembered having this discussion with someone a few months back, the idea being to use
the database in memory (ram drive) for faster access. However, you still want to guarantee that
your updates are safely stored, so you'd want the non-volatile copy to be your "safe" one, which
means forced-writes, and it means that each commit() -must- write to (each?) shadow file(s) before
returning. Your reads might be faster (assuming it all works) but your writes will need to sync
with the hard-drive, so it'll cost at least as much as it would have otherwise (what with writing
to two locations, though the memory one shouldn't be too expensive.) Also, you have to make sure,
for it to be useful, that the whole thing is going to stay in memory and not get swapped out by the
OS. But that's not really a DB issue.
For safety, writes must be expensive. For reads though, you might get some improvement. Note that
I'm assuming that Firebird makes sure shadows are as safe of a copy as you'd want/expect -- but as
it gets so many other things right ... it's gotta.
-Philip
---------- Original Message -----------
From: "Martijn Tonies" <m.tonies@...>
To: <firebird-support@yahoogroups.com>
Sent: Wed, 28 Apr 2004 09:37:32 +0200
Subject: Re: [firebird-support] Does the shadow get updated within the transaction?
the database in memory (ram drive) for faster access. However, you still want to guarantee that
your updates are safely stored, so you'd want the non-volatile copy to be your "safe" one, which
means forced-writes, and it means that each commit() -must- write to (each?) shadow file(s) before
returning. Your reads might be faster (assuming it all works) but your writes will need to sync
with the hard-drive, so it'll cost at least as much as it would have otherwise (what with writing
to two locations, though the memory one shouldn't be too expensive.) Also, you have to make sure,
for it to be useful, that the whole thing is going to stay in memory and not get swapped out by the
OS. But that's not really a DB issue.
For safety, writes must be expensive. For reads though, you might get some improvement. Note that
I'm assuming that Firebird makes sure shadows are as safe of a copy as you'd want/expect -- but as
it gets so many other things right ... it's gotta.
-Philip
---------- Original Message -----------
From: "Martijn Tonies" <m.tonies@...>
To: <firebird-support@yahoogroups.com>
Sent: Wed, 28 Apr 2004 09:37:32 +0200
Subject: Re: [firebird-support] Does the shadow get updated within the transaction?
> Hi Nigel,------- End of Original Message -------
>
> > > I guess the big question is, are shadow DB's updated in the same
> > > transaction, or can they lag behind (updated asynchronously)?
> > >
> > >
> >
> > I take it, then, that no-one know if the shadow database is updated in the
> > same transaction as the primary database...?
> >
> > Perhaps it's a prime candidate for an experiment...(wicked sinister
> chuckle)
>
> As far as I know, it's not on the transaction level, but
> rather on the I/O level that updates the shadow.
>
> With regards,
>
> Martijn Tonies
> Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
> Server.
> Upscene Productions
> http://www.upscene.com
>
>
> Yahoo! Groups Links
>
>
>