[This is preliminary documentation and subject to change]

# Metabase History Scenario 3

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

- The value of the HistoryMajorVersionNumber property within the in-memory metabase is at the maximum value of 9999999999.
- There are changes pending in the in-memory metabase and a write to disk event occurs.
- 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 handles major version number rollover.

It is unlikely that the HistoryMajorVersionNumbervalue will ever exceed the highest possible 10-digit value (9999999999), which is just under 10 billion. If the value of the HistoryMajorVersionNumber property exceeds the maximum value, however, the value of the HistoryMajorVersionNumber property rolls over to 1 or the next available HistoryMajorVersionNumber value as illustrated in this scenario.

Note The minor version number will never roll over because the in-memory metabase is automatically written to disk periodically, which causes the HistoryMajorVersionNumber value to increment automatically and the minor version number to be reset to zero.

Step 1:

1. The administrator stops the IISAdmin service.
2. The administrator opens MetaBase.xml using Notepad, changes the value of the HistoryMajorVersionNumber property to the maximum value of 9999999999, and saves MetaBase.xml.
3. The administrator restarts IIS.

When IIS is restarted, the MetaBase.xml file is read into the in-memory metabase.

Step 2:
The administrator changes the value of C (C=3) within the in-memory metabase and writes the in-memory metabase to disk.

1. IIS determines whether there are changes pending in the in-memory metabase. <Changes are pending.>
2. IIS locks the in-memory metabase to prevent writes.
3. IIS looks within the in-memory metabase for the value of the HistoryMajorVersionNumber property.
4. IIS then verifies whether a file within the history folder is named with a major version number equal to the HistoryMajorVersionNumber value plus 1. If a file exists in the history folder using this calculated major version number, IIS checks the history folder to determine whether the next higher major version number is available. This process is repeated until an available major version number is found.

   Note Because a file exists in the history folder (in this scenario) with the major version number of 1, IIS looks for a history file with a major version number of 2. IIS determines that the next available major version number is 2.

5. 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 4.
6. IIS unlocks the in-memory metabase to allow writes.
7. IIS copies the temporary file to the history folder and renames the file to MetaBase_0000000002_0000000000.xml.
8. IIS verifies that the MetaBase.xml file is not write-locked. <Passed verification.>
9. IIS verifies that the MetaBase.xml file is not read-only. <Passed verification.>
10. IIS verifies that the MetaBase.xml file is not newer than the temporary file. <Passed verification.>
11. 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.
12. IIS checks to determine whether the number of history file pairs contained in the history folder exceeds the value of the MaxHistoryFiles property. (A history file pair consists of a MetaBase.xml and MBSchema.xml history file versioned with the same major and minor version numbers.) If the number of history file pairs exceeds the MaxHistoryFiles value, the oldest history file pair, based on the timestamp value, is deleted.

phrase 1, phrase 2, phrase 3

© 1997-2001 Microsoft Corporation. All rights reserved.