Data Caching Problems

Symptoms may include:

• User 1 downloads the data of User 2 – this might happen if only one version of the data is cached because:
  • Two different CSI users are using different runtime credentials to access data from the backend, and the backend returns data based on the authenticated user.
  • The coherence window is larger than the interval in which the users are syncing.
• All users end up with data on the device that was originally cached by demand of a different device – this might happen if a customized download cursor is used by multiple CSI users using different load argument values (via different sync parameters).
• If a backend returns data based on an argument that is not filtered, because it is not an attribute of the MBO, all users will download that data by design. If you want to prevent this from happening, propagate the argument into an attribute, so that it can be used as a filter later.

Solution: Implement data partitioning in your MBO design. To enable partitioning of data by user for an MBO located in an cache group with a on-demand refresh policy:

1. Model an additional synchronization parameter and load argument onto the MBO that requires partitioning, and fill the load argument with the modeled sync parameter. The sync parameter should be filled with the implicit "username" personalization key.
2. Propagate the artificial load argument into an artificial attribute of the MBO which must be marked as part of the composite primary key of that MBO.
3. Map the synchronization parameter to the attribute into which the load argument was propagated.