Cache Groups

A cache group specifies the data refresh behavior for every mobile business object (MBO) within that group.

During development, you can group MBOs based on their data refresh requirements. Some terms and concepts you should be familiar with are:

Cache group – includes a cache policy and the MBOs that share that policy. An MBO can belong to only one cache group.
Cache – MBO data in the Unwired Server cache (CDB) can be refreshed according to a cache policy, along with other mechanisms, such as data change notification (DCN).
Cache policy – defines the cache refresh behavior and properties for the MBOs within the cache group based on the policy:
- On demand – the cache expires after a certain period of time such as 10 minutes. The cache is not updated until a request is made of the cache and the cache has expired. If a request is made of the cache and it is expired, there may be a delay responding to the request while the cache is refreshed.
- Scheduled – the cache is refreshed according to a schedule such as 7:00 am, 1:00 pm, or 6:00 pm. Note that load parameters filled from transient personalization keys can not be used with a scheduled cache type.
- DCN – the cache never expires. Data refresh is triggered by an enterprise information system (EIS) Data Change Notification. The cache interval fields are disabled when DCN is selected. See the Developer Guide for Unwired Server for details about implementing DCN.
- Online – only can be used with message-based mobile workflow applications. See Online Cache Group Policy.
Each cache group contains a cache policy, which in turn contains cache refresh/update properties. When a refresh occurs, the Unwired Server calls the default read operation (for each MBO in the cache group), and all of the rows that are returned from the enterprise information system (EIS) are compared to existing rows in the CDB as follows:
- If the CDB is empty, all rows are inserted.
- If any rows exist in the CDB, Unwired Server processes the row-set and checks (using the primary key) to determine if the row already exists in the cache:
  - If it does, and all columns are the same as the EIS, nothing happens. When a client synchronizes to request all rows that have changed since the last synchronization, only rows that have changed are included, which is important for performance and efficiency.
  - If the row does not exist, it is inserted and the next synchronization query retrieves the row.

Cache Group Considerations
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 onDemand cache policy with a large coherence window is a more appropriate cache solution than an hourly schedule-based refresh.
Creating Cache Groups
Cache group folders define the data refresh schedules for the mobile business objects (MBOs) within them. Create as many cache groups as required to meet the varying data refresh needs of the MBOs for a given mobile application project.
Modifying Cache Group Properties
Modify common and policy properties for cache groups.
Assigning Mobile Business Objects to a Cache Group
Assign mobile business objects (MBOs) to a cache group based on the group's data refresh needs. Once deployed to Unwired Server, the cache policy determines the data refresh policy for each cache group.
Online Cache Group Policy
Adding MBOs to a cache group that uses the Online policy indicates that the MBOs are to be used only in Workflow forms where access to real-time enterprise information system (EIS) data is required. Data is delivered to the Workflow client based on the findByParameter object query definition.

Parent topic: Mobile Business Object Mobility Properties