Home | 2.6.5 Cache programming support | 2.6.7 Invalidation rules overview <invalidation>


2.6.6 Dependency ID overview <dependency-id>

Dependency ID elements are used to ensure related cache items that become out-of-date as a group are all evicted as a group. This process is known as invalidation. Each related cache item shares the same dependency ID, so it only takes one member of the dependency group to get invalidated, for the rest of the group to be evicted.

The dependency ID can be as simple as just a name, such as "storeId," for example, <dependency-id>storeId</dependency-id>. In this example, storeId can be referred to as the base string.

Dependency ID definitions are often more complex. You can specify additional sub-components that are appended one-by-one to the dependency to create a more refined invalidation key.

Suppose you want to invalidate only selected pages that apply to a particular store. The dependency ID will need some way of identifying that store. You implement this by using <component id> tags. Each <component id> tag declares additional string data that is appended to the base name string to form the final, fully qualified dependency ID string.

<dependency-id>storeId

    <component id="" ignore-value="true" type="pathinfo">
        <required>true</required>
        <value>/StoreCatalogDisplay</value>
        <value>/TopCategoriesDisplay</value>
        <value>/CategoryDisplay</value>
        <value>/ProductDisplay</value>
    </component>
    
    <component id="storeId" type="parameter">
        <required>true</required>
    </component>

</dependency-id>

Note that if any of the required <component> elements are missing, (meaning the parameters that you specified as required) then the dependency ID rule is discarded by the runtime engine. Multiple <dependency-id> rules can exist per cache entry. All dependency ID rules execute separately. We cover dependency IDs in greater detail in the invalidation chapter.

+

Search Tips   |   Advanced Search