-----Original Message----- From: Erik Enge [mailto:erik@src.no]

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 update.

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. :-) -cw-