If you are experiencing problems with getting your pages to be cached properly using dynamic caching, consult the following information:
- The Cache Monitor is not accessible.
- Ensure you have regenerated the Web Server plug-in and restarted the Web server and the application server so that the new virtual host and port number mappings are loaded.
- No pages whatsoever are being cached.
- Verify that the cachespec.xml file has been loaded into WebSphere Application Server. If the cachespec.xml is loaded, then the policies should be viewable from the Cache Monitor by clicking on the Cache Policies link on the side bar. In addition the WebSphere Application Server SystemOut.log file will show a line similar to:
[6/6/03 21:21:12:635 EDT] 65c60609 ConfigManager I DYNA0047I: Successfully loaded cache configuration file D:\WebSphere\AppServer5\installedApps\buzz\WC_demo.ear\ Stores.war\WEB-INF\cachespec.xml.
Note that the above line has been split for display purposes.
- Only some of your pages are being cached.
- There is in all likelihood a problem with the cachespec.xml file. You can turn on the trace and then access the page under being investigation. The trace should indicate the problem.
- To turn on the Dynamic Cache trace (WebSphere Commerce side), the Trace Specification should contain "com.ibm.websphere.commerce.WC_CACHE=all=enabled".
- To turn on the Dynamic Cache trace (WebSphere Application Server side) the Trace Specification should contain "com.ibm.ws.cache.*=all=enabled".
- The DynaCacheInvalidation command does not invalidate.
- Verify that the command is functional from the URL. If you do need to run the command from the URL, then the cacheinvalidation.jsp file must be in the docpath. Even if it is not in the path, the command will run however you will not receive a display page to report its completion. Once the URL invocation is correct, you can verify whether it has been scheduled to run through the WebSphere Commerce scheduler, the default is to run unscheduled.
- Invalidation through dependency ID does not work properly.
- Verify that the dependency ID for the intended servlet or JSP file is within the same cache-entry block. If this is the case, you must ensure that multiple definitions of the same dependency ID in different cache entry blocks have the identical definition. That is, if your dependency id is defined for some cache-entry as follows, the definition of the dependency ID in any other cache-entry block must be exactly the same:
<dependency-id>storeId <component id="storeId" type="parameter"> <required>true</required> </component> </dependency-id>
- Changes to JSP pages have no affect or are not visible
- Every time you make changes to a compiled JSP page (for example, myhomePageContent.jsp) the changes do not take affect or are not visible when you load that page. You are finding that the only way for the changes to be visible is to restart your WebSphere Commerce instance.
In order to avoid restarting your instance, you need to reset the "reloadInterval" to a smaller value. Edit the file ibm-web-ext.xmi, usually located in the following directory:
WAS_installdir/config/cells/your_cell_name/applications/WC_instance_name.ear/deployments/WC_instance_name/Stores.war/WEB-INF/ibm-web-ext.xmi
WAS_installdir\config\cells\your_cell_name\applications\WC_instance_name.ear\deployments\WC_instance_name\Stores.war\WEB-INF\ibm-web-ext.xmi
Search for "reloadInterval" and reduce its value. Also, ensure that reloadingEnabled="true" is set. You will have to restart the WebSphere Commerce instance, WC_instance_name, for your modification to take effect. The value of reloadInterval determines when a thread starts up to check if the JSP source file has changed so that the next time a request comes for that JSP, the new source is compiled. If the interval is too large, the JSP file is not recompiled until the thread starts up again, even though your source has changed and the compiled class is removed. Note that there will be a slight performance impact if you set reloadInterval too low, since the thread will have to check for changes more frequently. See the information on "Reload interval" and "Reloading enabled" in the topic "Web modules assembly settings" in the WebSphere Application Server Information Center. Also refer to the topic "Hot deployment and dynamic reloading" for additional information. - Cacheable objects cannot be created or invalidated due to encrypted URL parameters
- When parameters and the values in a Web address are encrypted, the WebSphere Commerce dynamic caching mechanism cannot use them to form, or to invalidate, cache entries. If you are encrypting those parameters, you need to modify your instance.xml file, to specify the parameters that you do not want encrypted. This is the standard way to resolve encrypted parameter related problems for caching.
For example, to specify that the storeID and langID parameters are not to be encrypted, you can add the following <NonEncryptedParameters> tag after the <ProtectedParameters> in your instance.xml file as shown below:
... <ProtectedParameters> ... </ProtectedParameters> <NonEncryptedParameters> <Parameter name="storeId"/> <Parameter name="langId"/> </NonEncryptedParameters> ...