Shared transactional data has a higher chance of being stale until it becomes consistent again.
Multiple users can update the same instance leading to race conditions. While it is possible to provide higher consistency through the On-Demand policy with a zero cache interval, the cost can also be high, depending on the data volume involved in a refresh. This approach is feasible if the use case is such that each user is retrieving 10-20 object graphs shared with other users. A use case that leverages a user identity partition means that an instance belongs to multiple partitions as it is shared. For example, an approval request that is assigned to two managers shows up in two partitions. This condition violates the restriction that each member can only belong to one partition. It also means that the member bounces between partitions. To resolve this, add the user identity as part of the primary key so the cache sees a unique instance for the partition. In this scenario, the load argument corresponding to the user identity should be propagated to an attribute. The other alternative is to use the "partition by requester and device id" option in the cache group settings. With this setting, the instance identity is automatically augmented with the requester/device ID so there is never partition bouncing.
Load via Pull - High Consistency
 |
Use an On-Demand cache group policy with a zero cache interval. |
|
Use “Immediately update the cache” cache policy if create operations form the association between the surrogate key and business key. |
|
Use a notification MBO to implement targeted change notification (TCN), previously called server-Initiated synchronization (SIS) if required. |
|
Augment the primary key to avoid instance bouncing between partitions at the expense of duplication. |
 |
Ensure the EIS can handle peak on-demand requests based on expected client load. |
Load via Pull
|
Use an On-Demand cache group policy with a non-zero cache interval. |
|
Use “Immediately update the cache” cache policy for all operations. Users see each others changes. |
|
SIS/TCN is activated by changes made by other users. Changes from the EIS are only detected at expiration of the cache interval. |
 |
Do not use a partition since it creates duplicate copies of valid data until the interval expires. This creates further inconsistency between users. |
Load via Push
|
Use a single queue in the EIS for each individual MBO or object graph to avoid data inconsistency during updates. This is not required for initial loading since each instance/graph is sent once. |
|
Use a notification MBO to indicate initial loading is complete. |
|
Adjust the change detection interval to satisfy data freshness requirements. |