Partitioning the Unwired Server cache (CDB) divides it into segments that can be refreshed individually, which gives faster system performance than refreshing the entire CDB.
Cache partitioning is determined by a partition key, which is a load parameter used by the operation to load data into the cache from the enterprise information system (EIS).
Define a partition key from a mobile business object (MBO) attribute column, or define a composite partition key from multiple attributes. A device application user specifies a value for the load parameter when synchronizing his or her client application, possibly through a personalization key that is also used as a synchronization parameter.
All cache partitions require a load parameter:
- Create cache partitions through a load parameter specified by the client, for example, a load parameter that uses the synchronization parameter option and maps to a personalization key.
- Refresh a cache partition if data in the partition is:
- Expired
- Invalidated
- Inconsistent – if a client has multiple partitions, refresh all partitions even if only one partition expires.
- If the MBO is defined with something other than "=" in the where clause, manually edit, in the synchronization tab, the SQL code for the customized download data.
- Although you create a partition key based one or more MBO attributes, you rarely use the primary-key column, since doing so creates a partition for every row in the CDB. The goal of partitioning is to place only the data you need in a partition.
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 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.