[This is preliminary documentation and subject to change]

Metabase History Scenario 1

This scenario illustrates how edit while running works under the following conditions:

You will learn:

How IIS writes the in-memory metabase to disk when all checks pass.
How history files are versioned and named when the in-memory metabase is written to disk.

Action taken: A write-to-disk event occurs.

IIS performs a series of verifications as seen below. Refer to Writing the Metabase to Disk for more information about the verifications.

Describes step 1 of this scenario.

IIS verifies that there are changes pending in the in-memory metabase.
IIS locks the in-memory metabase to prevent writes.
IIS determines the major version number.
IIS creates a temporary file containing the in-memory metabase configuration. Note: The value of the HistoryMajorVersionNumber property that was determined in step 3 is written within the temporary file.
IIS unlocks the in-memory metabase to allow writes.
IIS copies the temporary file to the history folder and renames the file with the major and minor version numbers.
IIS verifies if the MetaBase.xml file is write locked. <Passed Verification>
IIS verifies if the MetaBase.xml file is read-only. <Passed Verification>
IIS verifies if the MetaBase.xml file in newer than the temporary file. <Passed Verification>
Because the MetaBase.xml file is not write locked, not read-only, and is not newer than the temporary file, the temporary file is copied over MetaBase.xml, and the temporary file is deleted.
IIS checks to determine whether the number of history file pairs contained in the history folder exceed the value of the MaxHistoryFiles property. A history file pair is a MetaBase.xml and MBSchema.xml history file versioned with the same major and minor version numbers. If the number of history file pairs exceed the MaxHistoryFiles value, the oldest history file pair, based on the timestamp value, is deleted.

phrase 1, phrase 2, phrase 3