Home | 2.6.7 Invalidation rules overview <invalidation> | 2.6.9 Delay-invalidations
2.6.8 Command-based invalidation
Invalidation rules are activated by the execution of a Java command, which you can write yourself. A Java command class extends from the WebSphere Command Framework API. Invalidation IDs for command-based invalidation are constructed based on methods and fields provided by the commands.
The values of the <name> elements in Example | -5 are two classes that belong to the Java package: com.ibm.commerce.catalogmanagement.commands.
The two classes are:
- AddCatalogDescCmdImpl
- UpdateCatalogDescCmdImpl
Both of these catalog management classes implement the command-based interfaces defined in the command framework. DynaCache hooks into the methods defined in the command interface. Command execution is carried out in a method called performExecute(), which the latter classes must implement.
Both of these catalog management classes update the ConsumerDirect application's catalog descriptions. In this example, the cache designer has created invalidation rules that run based on either of these classes having their performExecute() methods called. By default, the invalidations occur prior to the performExecute() command actually being called; however, you can change it to occur after performExecute() returns if necessary using the delay-invalidations property which we discuss later.
The example below specifies a policy to invalidate any cache entries that are identified by the same storeId and catalogId. DynaCache intercepts calls to the AddCatalogDescCmdImp and the UpdateCatalogDescCmdImpl commands (which add or update a catalog description entry) and generates the invalidation ID based on the value returned by the getStoreId() and getCatalogId() methods. Upon execution of the commands, the DynaCache compares the invalidation IDs with each of the dependency IDs. Any cache entry for which any of its dependency IDs matches with any of the invalidation IDs is removed.
The invalidation ID is generated by concatenating the invalidation ID base string with the values returned by its component element. If a required component returns a null value, then the entire invalidation ID is not generated and no invalidation occurs. Multiple invalidation rules can exist per cache-entry. All invalidation rules execute separately.
If you take a look at the snippet of XML that performs the CategoryDisplay invalidation in Example | -6, you can see that base ID (defined by the <invalidation> tag) is CategoryDisplay:storeId:catalogId and there are two further components making up the ID. The two components are the returned string results obtained by calling the methods getStoreId() and getCatalogId().
With a store ID of 511 and a catalog ID of 8003, an invalidation ID of CategoryDisplay:storeId:catalogId:511:8003 is created.
<!-- ********************************* --> <!-- CategoryDisplay Invalidation --> <!-- ********************************* --> <invalidation>CategoryDisplay:storeId:catalogId <component id="getStoreId" type="method"> <required>true</required> </component> <component id="getCatalogId" type="method"> <required>true</required> </component> </invalidation>