JasperReports Server caches your data when a user opens an OLAP view, Ad Hoc view, or OLAP-based report. These data are reused if they are subsequently requested before the cache is flushed. To determine whether a new request can be fulfilled with cached data, the server creates an identifier (by combining several connection attributes of the OLAP schema (such as catalogUrl, connectionKey, jdbcUser, dataSourceStr (or catalogUrl), and dataSource)). The server then compares the identifier to those of datasets in the cache. If it matches one, the data is reused; otherwise, the server assumes that this is a unique request and loads new data into the cache.
Alternatively, you can configure the server to compare schemas’ checksums. In this cases, the server calculates the checksum of the schema being loaded and compares it to the checksums of schemas with datasets in the cache. If it matches one, the data are reused; otherwise, the server assumes that this is a unique request and loads new data into the cache.
If you want the server to identify datasets in the OLAP cache using a checksum, you can edit a configuration file:
| OLAP Schema Checksum Comparison for Caching | ||
| Configuration File | ||
| …WEB-INFclassesmondrian.connect.string.properties | ||
| Property | Description | |
| UseContentChecksum | When this property is set to true, JasperReports Server calculates an OLAP schema's checksum and compares that to checksums of schemas with datasets already in the cache. If it matches one, the data are reused; otherwise, the server assumes that this is a unique request and loads new data into the cache. | |
| | Jaspersoft recommends caution if you configure the server to identify datasets by the checksum of the associated OLAP schema. Under very specific circumstances, setting this property to true can cause unexpected behavior in which cached data are reused incorrectly. Users might see data associated with a different schema whose data is already in the cache simply because the checksums match. The following scenario presents one such case, though others are certainly possible. |
Consider this server configuration:
| • | The JasperReports Server instance hosts two organizations: Client1 and Client2. |
| • | Each organization has a user responsible for data analysis: |
| • | Client1's data analyst is Amber. |
| • | Client2's data analyst is Huan. |
| • | Each organization includes an OLAP-based report that uses identical OLAP schemas: |
| • | Client1 |
| • | Report: Sales Leads OLAP Report (C1) |
| • | OLAP Schema: SalesLeadsSchemaC1 |
| • | Client2 |
| • | Report: Sales Leads OLAP Report (C2) |
| • | OLAP Schema: SalesLeadsSchemaC2 |
| • | Each OLAP schema relies on a different database with the same data structures, so that the users in each organization see their own data. |
Now consider this use case:
| 1. | Amber (in the Client organization) opens the Sales Leads OLAP Report (C1). |
Amber sees sales leads generated by Client1. In the cache, this data is identified by the checksum of the SalesLeadsSchemaC1 schema.
| 2. | Before the cache is flushed, Huan (in the Client2 organization) opens the Sales Leads OLAP Report (C2). |
By default, Huan sees sales leads generated by Client2 (which is the expected result). However, when the UseContentChecksum property is set to true, the server compares the checksum of the SalesLeadsSchema2 with the checksum in the cache. Because this checksum matches the checksum of SalesLeadsSchema1 (the schema loaded by Amber), the server returns the cached data instead of loading data from Client2's data source.
| | In this scenario, Huan sees another client’s sales data. |
If your JasperReports Server instance hosts multiple organizations, Jaspersoft recommends that you use the default setting and allow the server to identify OLAP datasets using their connection URL details.
Note that other scenarios can cause similar unexpected behavior when the UseContentChecksum property is set to true; two checksums could conceivably match for any number of unpredictable reasons.
Recommended Comments
There are no comments to display.