[This is preliminary documentation and subject to change]

Edit-While-Running Scenario 7

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

What you will learn:

note Note    For the purpose of this scenario, it is not important to know the values contained within the in-memory metabase or the metabase files; only the version numbers of the metabase files are relevant.

Step 1:
An administrator opens MetaBase.xml using Notepad and changes but does not save the file.

Describes step 1 of this scenario.

Step 2:
Several hours pass, during which time the in-memory metabase is written to disk nine times. The result is that several new history files are created within the history folder.

Describes step 2 of this scenario.

Step 3:
The in-memory metabase is changed and saved to disk again.

Describes step 3 of this scenario.

When the in-memory metabase is changed and saved to disk, the following happens:

IIS performs a series of verifications as detailed in Writing the Metabase to Disk.

  1. IIS verifies that there are changes pending in the in-memory metabase.
  2. IIS locks the in-memory metabase to prevent writes.
  3. IIS determines the major version number.
  4. IIS creates a temporary file containing the in-memory metabase configuration.
  5. IIS unlocks the in-memory metabase to allow writes.
  6. IIS copies the temporary file to the history folder and renames the file with the major and minor version numbers.
  7. IIS verifies that MetaBase.xml is not write-locked. <Passed verification.>
  8. IIS verifies that MetaBase.xml is not read-only. <Passed verification.>
  9. IIS verifies that MetaBase.xml is not newer than the temporary file. <Passed verification.>
  10. The temporary file is copied over MetaBase.xml, and then the temporary file is deleted.
  11. 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 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 exceeds the value of the MaxHistoryFiles property, the oldest history file pair, based on the timestamp value, is deleted.

note Note    In step 12, the corresponding history file, which was named MetaBase_0000000001_0000000000.xmlnote Note    , was deleted.

Step 4:
The administrator saves the copy of MetaBase.xml with Notepad but does not close Notepad.

Describes step 4a of this scenario.

When MetaBase.xml is edited and saved, the following happens:

  1. IIS receives a file change notification that the MetaBase.xml file has been saved.
  2. IIS looks within the MetaBase.xml file for the HistoryMajorVersionNumber value.
  3. IIS looks within the history folder for the corresponding history file. The corresponding history file is the file with the same HistoryMajorVersionNumber value that was found in step 2, with the highest minor version number.
  4. Because the corresponding history file is not found, IIS copies MetaBase.xml to the history folder and renames the file to MetaBaseError_0000000000.xml.
  5. IIS sends an error to the event log.
  6. A new history file is created, and the oldest is deleted.

important Important    Whenever an error file is created, to protect against the possibility that the MetaBase.xml file may be non valid or corrupt, the in-memory metabase is written to disk.

Describes step 4b of this scenario.

note Note    When IIS checks the MaxHistoryFiles property against the number of files in the history folder, the error files are not counted. Therefore, the file named MetaBase_0000000003_0000000000.xml is not deleted.

Step 5:
Make a change using Notepad, save MetaBase.xml, and then close Notepad.

Describes step 5a of this scenario.

When MetaBase.xml is edited and saved, the following happens:

  1. IIS receives a file change notification that the MetaBase.xml file has been saved.
  2. IIS looks within the MetaBase.xml file for the HistoryMajorVersionNumber value.
  3. IIS looks within the history folder for the corresponding history file. The corresponding history file is the file with the same HistoryMajorVersionNumber value that was found in step 2, with the highest minor version number.
  4. Because the corresponding history file is not found, IIS copies MetaBase.xml into the history folder and renames the file to MetaBaseError_0000000001.xml.
  5. IIS sends an error to the event log.
  6. The in-memory metabase is saved to disk.
  7. A new history file is created, and the oldest history file is deleted.

Describes step 5b of this scenario.

phrase 1, phrase 2, phrase 3

© 1997-2001 Microsoft Corporation. All rights reserved.