Title: RE: [Zope] Backing Up Zope (was: Re: [Zope] Data.fs.lock?)

> -----Original Message-----
> From: Erik Enge [mailto:[EMAIL PROTECTED]]
> On Thu, 29 Jun 2000, Jeff K. Hoffman wrote:
> > It is my understanding that the ZODB on disk is always in a
> consistent
> > state; Jim has said, in the past, that you can simply make a copy of
> > Data.fs, even while Zope is running, without problems.
> But the Data.fs has to be updated sometimes.  And if you read
> from a file
> that is changing, the integrity of your data isn't.  How can
> you make sure
> that the file is not written to during a certain period of time?  You
> can't?

You can.

This would be consistent with "atomic updates."  What it means is
that a transaction is not written to the Data.fs file until it has
completed, and when it is finally written out, it's done as an
atomic operation, i.e. at the system level it is a single write
operation and nothing else happens on the system until it completes.

From that you can infer that if you were reading the Data.fs file
(making your backup copy) at the same time, it would be impossible
to read the file "in the middle of an update."  If both read and
write requests hit Data.fs at essentially the same time, one goes
first and the other waits until the first completes.  So if the
write gets first shot, the read will block until the write (meaning
a completed transaction/update) finishes, and your read will include
that last update.  If your read gets first shot, then it will not
include the update.  You will under no circumstances get *half* an

One of the other things that makes this possible is ZODB being of
a "journaling" nature.  i.e., all updates are *appended* to Data.fs.
This is why you must periodically pack the database, which
conglomerates all the updates back into the base datastore (or
whatever those wacky Zopistas call it. ;) that comprises the first
part of the Data.fs file.

I think that's all correct.  Someone please throttle me senseless
if not.  :-)


Reply via email to