[This is preliminary documentation and subject to change]

Metabase History Scenario 4

This scenario illustrates how the metabase history feature works under the following conditions:

An administrator copies an old version file into the history folder.
The value of the HistoryMajorVersionNumber property within the in-memory metabase is at the maximum value of 9999999999.
MetaBase.xml is not write-locked.
MetaBase.xml is not read-only.
MetaBase.xml is not newer than the temporary file.

What you will learn:

How IIS avoids overwriting files in the history folder that have non sequential version numbers.

Step 1:
Copy MetaBase_0000000001_000000000.xml into the history folder.

Describes step 1 of this scenario.

Step 2:
Change the value of A (A=3) within the in-memory metabase, and write the in-memory metabase to disk.

Describes step 2 of this scenario.

IIS determines whether there are changes pending in the in-memory metabase. <Changes are pending.>
IIS locks the in-memory metabase to prevent writes.
IIS looks within the in-memory metabase for the value of the HistoryMajorVersionNumber property and increments this value by 1. IIS then checks whether a file within the history folder is named with the same major version number. If a file exists in the history folder using the same major version number, IIS checks the history folder to determine whether the next higher version number is available. This process is repeated until an available major version number is found.
Note Because the HistoryMajorVersionNumber value within the in-memory metabase is at the maximum value in this scenario, the value is rolled over to 1 and IIS looks for a history file with a major version number of 1. IIS determines that the major version number 1 is available.
IIS writes a temporary file with the contents of the in-memory metabase and writes the value of the HistoryMajorVersionNumber property within the temporary file that was determined in step 3.
IIS unlocks the in-memory metabase to allow writes.
IIS copies the temporary file to the history folder and renames the file to MetaBase_0000000001_0000000000.xml.
IIS verifies that the MetaBase.xml file is not write-locked. <Passed verification.>
IIS verifies that the MetaBase.xml file is not read-only. <Passed verification.>
IIS verifies that the MetaBase.xml file is not 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.

Step 3:
Change the value of B (B=3) within the in-memory metabase, and write the in-memory metabase to disk.

Describes step 3 of this scenario.

IIS determines whether there are changes pending in the in-memory metabase. <Changes are pending.>
IIS locks the in-memory metabase to prevent writes.
IIS looks within the in-memory metabase for the value of the HistoryMajorVersionNumber property and increments this value by 1. IIS then checks whether a file within the history folder is named with the same major version number. If a file exists in the history folder using the same major version number, IIS checks the history folder to determine whether the next higher version number is available. This process is repeated until an available major version number is found.
Note Because the HistoryMajorVersionNumber within the in-memory metabase was at the maximum value, the value is rolled over to 1. IIS determines that the next available major version number is 3.
IIS writes a temporary file with the contents of the in-memory metabase and writes the value of the HistoryMajorVersionNumber property within the temporary file that was determined in step 3.
IIS unlocks the in-memory metabase to allow writes.
IIS copies the temporary file to the history folder and renames the file to MetaBase_0000000001_0000000000.xml.
IIS verifies that the MetaBase.xml file is not write-locked. <Passed verification.>
IIS verifies that the MetaBase.xml file is not read-only. <Passed Verification>
IIS verifies that the MetaBase.xml file is not 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.

phrase 1, phrase 2, phrase 3