Problem: A data caching problem is detected, or data caching is not operating as expected.
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 device 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 load 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 a cache group with a on-demand refresh policy:
- 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 system personalization key "username".
- 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.
- Map the synchronization parameter to the attribute into
which the load argument was propagated.