There are some situations where data caching is handled differently.

Caching in Product Details and Inventory

Core data is used to cache product details since they are not expected to change. Since inventory can change often it is requested every time the product is viewed. This means the product detail and the inventory requests are separate. For example, on first view, two requests are made, but for subsequent views, only inventory is fetched since the product is cached in core data.

In CRS-IUA, this is done to balance performance and data integrity. You should consider the same practice. For example, in CRS-IUA, the shopping cart is not cached to ensure data integrity, since we want the monetary amount the customer is committing to be as accurate as possible, even if it means that some performance could be sacrificed.

Limit Data in Response with Filtering Configuration

REST filtering can be used to limit data response. See the section REST Filtering for more information.

Apple’s Version of Repositories

Apple’s CoreData is similar to how Oracle Commerce Repositories work. Both are Object-relational mapping (ORM) frameworks that manage the saving to a SQL database for you.

Persistent Between Sessions

“Persistent between sessions” means that even after the user closes the iOS app, the cache is still present, when they return and open up the app, since CoreData is written to disk, thus saving data between sessions. With in-memory, the memory is discarded when the app is closed and therefore the cache empty when the app restarted. Things that change infrequently can be persisted between sessions with little fear of things being out of date. It is important to note that iOS has the concept of “sleeping” an app when you close it. In that case the memory is not discarded. In either case, the cache timeout still comes into play so if the app is closed for a very long time it does not really matter that much.

Simple Caching

In Oracle Commerce Repositories terminology, simple caching is time based, since there is not a way to disseminate cache invalidation events to remote mobile devices.

Use CoreData When Data Changes Infrequently

Since CoreData is written to disk and is best used for data that does not change frequently.

Timeouts

Timeouts are the number of seconds for the cache is configured for Product and Stores respectively. Each manager will have a constant for its cache life number of seconds, both for in-memory and core data.

Item

Constant

Manager

Product

PRODUCT_CACHE_TIME_OUT_SEC

ATGProductManager

Store

STORE_CACHE_TIME_OUT_SEC

ATGStoreManager


Copyright © 1997, 2016 Oracle and/or its affiliates. All rights reserved. Legal Notices