Define multiple cache groups for data based on specific usage patterns
and consistency tolerance. For example, for transactional data that has little tolerance for
EIS data that is stale, an On-demand cache policy with a large coherence window is a more
appropriate cache solution than an hourly schedule-based refresh.
Some best practices for defining cache groups and allocating MBOs to those groups include:
- Place all MBOs that are modeled with composite relationships in the same cache group.
- Do not place Reference data and transactional data in the same cache group.
Typically, reference data has different data consistency requirements than
transactional data. For example, a SalesOrder MBO that has a composite
relationship to SalesOrderItem MBO, which contains a reference (non-compoiste)
relationship to Product. Since products do not change as often as sales order
items, you may want to put the Product MBO in a different cache group.
- Avoid circular dependencies between cache groups.
- Avoid loading of an MBO in one cache group
based on the attributes of an MBO in another cache group.
On-demand versus scheduled refresh
Cache policy refresh options affect cache partitions, in that they determine the
frequency with which the CDB is updated from the EIS (data refresh). The scheduled
refresh option refreshes the cache based on a clock. The on-demand refresh option,
which is based on client actions, is discussed here, with an emphasis on how to
determine if cache partitions behave as expected.
To validate CDB data partition refresh behavior:
- Define multiple partitions and multiple clients.
- Define a cache group with an On demand policy and confirm cache refresh
behavior. Set the cache policy with a cache interval that is long enough to
allow you to perform updates to the EIS and synchronize both clients.
- Wait until the cache interval passes, then resynchronize the clients. The
second synchronization should reflect EIS changes, since the cache policy
dictates that the CDB must now refresh.
- Inspect CDB log files for time stamps in the "LAST_REFRESH" and "LMD"
columns for your package to confirm that the partitions and rows of data for
the associated partitions have refreshed as expected.
To confirm the correct partitions have refreshed:
- Make updates to data from multiple partitions in the EIS.
- Synchronize one client so only one partition refreshes. Make sure the values
for the length of the cache interval and the last time the partition
refreshed indicate that the data in that partition is stale and needs to
refresh when you synchronize.
- The synchronized client retrieves refreshed rows only from the partition of
interest. Data from other EIS partitions do not update the CDB, even though
data has changed in the EIS (because no client has requested a
synchronization of that partition).
- When the second client synchronizes the second partition, only that
partition refreshes.