KB5824: How are report caches matched in MicroStrategy Intelligence Server 9.x and later?

When a user requests a report, cache keys are used to determine if a cache can be used to satisfy the request. If the cache keys in the report request match the ones in the report cache, the cache is used. The matching process takes several steps that involve a number of cache keys, and each step is explained in detail below. If at any step, the matching is not successful, then the cache is not used and the report request executes against the data warehouse.
 

1. Basics To check whether the requested report and the cached report are the same, Intelligence Server compares the Report IDs and Report Version IDs of the two. If they match, the process continues to Step 2. Alternatively, Intelligence Server checks the Template ID, Template Version ID, Filter ID and Filter Version ID in the requested report against the ones in the report cache. If all of them match, the process continues to Step 2.
2. Personalization impact Intelligence Server checks the prompt answers selected for the report. Different prompt answers change the content of the report; therefore, the cache is not used if the prompt answers in the report request are not the same as the ones in the report cache. Each set of distinct prompt answers yields a distinct cache.
3. Security impact Intelligence Server makes sure that users with different security filters cannot access the same cache. Intelligence Server compares the Security ID and Security Version ID of all the security filters applied to the user in the report request, including those inherited from the groups to which he or she belongs, with the security profile of the user who originated the report cache.
4. Modification impact Intelligence Server makes sure a cache is not used if there is a change to an object in the report. To do so, Intelligence Server compares the IDs and Version IDs of all other application objects used in the requested report with the ones used in the cache report. If they are different, the existing cache is automatically invalidated.
5. Other criteria (optional) These criteria are useful if Database Security View and Connection Mapping are used to ensure that users with different security profiles, who see different data from the data warehouse, cannot access the same cache.
   
1. User ID: global unique identifier (GUID) of the user, if the Create caches per user check box is selected in the Caching: Reports (Advanced) category in the Project Configuration editor.
   
2. Database Login: GUID of the database login assigned to the user via the Connection Mapping or if the Create caches per database login check box is selected in the Caching: Reports (advanced) category in the Project Configuration editor. The latter is especially useful if Database authentication mode is used.
   
3. Database connection: GUID of the database connection assigned to the user via the Database Instances: Connection Mapping option in the Project Configuration editor or if the Create caches per database connection check box is selected in the Caching: Reports (Advanced) category in the Project Configuration editor
   

These optional criteria settings are shown in the screen below.