Use either pull or push loading strategies for private transaction data.
- Read and write
- Can be updated by both the mobile application and EIS
- Moderate change frequency
- High freshness expectation
- No sharing between users
- Access pattern varies depending on use case: morning/evening or throughout the day
- Moderately low data volume (not including historical data which is considered as reference)
If data freshness and consistency is of high priority, then an on-demand cache group policy is the more suitable approach. DCN, however, allows for change detection and targeted change notification (TCN), previously called server-Initiated synchronization (SIS) without additional work.
Load via Pull
 |
Partition per user using either the “Partition by requester and device identity” feature in the cache group policy, or a specific identity provided by the developer. |
|
Use an on-demand cache group policy with a zero cache interval for consistency and high data freshness. |
|
Use the "Immediately update the cache" cache policy if there are create operations that associate a surrogate key and a business key. |
|
Use a notification MBO to implement TCN/SIS if required. |
 |
Ensure that all members of a partition belong to only one partition. |
|
Ensure the EIS can support peak on-demand requests based on expected client load. |
 |
Do not use a scheduled cache group policy. |
Load via Push
|
Use parallel DCN streams for the initial load if there is a large user population. |
|
Use Unwired Server clustering to scale up data loading. |
|
Use a single queue in the EIS for each individual MBO or object graph to avoid data inconsistency during updates. You can relax this policy for initial loading, as each instance or graph is sent only once. |
|
Use a notification MBO to signal that initial loading is complete. |
|
Adjust the change detection interval to satisfy any data freshness requirements. |
|
Always use the "Immediately update the cache" cache policy for all operations. |