Repository Cache Modes in ATG Commerce

Efficient database access is important to many ATG applications. You should design an application so it requires minimal access to the data base and ensures data integrity. An intelligent caching strategy is central to achieving these goals.

Item Caches & Query Caches

For each item descriptor, an SQL repository generally maintains two caches:

·         Item Caches

·         Query Caches

Item Caches

Item caches hold the values of repository items, indexed by repository IDs. An item cache entry is invalidated when that item is updated. The scope of an entry’s invalidation depends on its caching mode.

Query Caches

Query caches hold the repository IDs of items that match given queries. When a query returns repository items whose item descriptor enables query caching, the result set is cached as follows:

·  The query cache stores the repository IDs.

·  The item cache stores the corresponding repository items.

A query cache entry can be invalidated for two reasons:

· A cached item property that was specified in the original query is modified.

· Items of a queried item type are added to or removed from the repository.

If query caching is enabled, the first time this query is issued, the result set is retrieved from the database and stored in the query cache. Then, the next time this same query is issued, the SQL repository can retrieve the result set from the cache, rather than needing to access the database.

Cache Modes

The SQL repository implements several different modes of caching. Which mode is to be chosen depends on the nature of your Dynamo application. We can set the default caching mode on each item descriptor in a repository. Each property’s definition can override the cache mode of its item-descriptor.

The caching modes implemented in the SQL repository are:

•          No Caching (disabled)

When caching is disabled for an item, its property values are cached only during the current transaction, and only if the transaction requires one or more of that item’s properties. This ensures a consistent view of item data while the transaction is in progress. Thus, multiple calls to getPropertyValue() for the same property within the same transaction require only one database query. Cached item properties are reloaded from the datastore for each transaction.

•          Inherited

You can set a property to inherit the default caching mode by setting its cache-mode attribute to inherit. This setting can be useful when a property’s caching mode is set to disabled at one point in the configuration path and you want to reset the property to the default caching mode at a later point.

•          Simple Caching (caching is handled separately in each VM, with no invalidation events to synchronize updates from different server instances).

A server obtains changes to an item’s persistent state only after the cached entry for that item is invalidated. This mode is suitable for read-only repositories such as product catalogs, where changes are confined to a staging server, and for architectures where only one server handles a given repository item type.

•          Locked Caching (read and write locks are used to synchronize the caches)

A multi-server application might require locked caching, where only one ATG instance at a time has write access to the cached data of a given item type. You can use locked caching to prevent multiple servers from trying to update the same item simultaneously.

Prerequisites

Locked caching has the following prerequisites:

·   Item descriptors that specify locked caching must disable query caching by setting their query-cache-size attribute to 0.

· A repository with item descriptors that use locked caching must be configured to use a ClientLockManager component; otherwise, caching is disabled for those item descriptors. The repository’s lockManager property is set to a component of type atg.service.lockmanager.ClientLockManager

· At least one ClientLockManager on each ATG instance where repositories participate in locked caching must be configured to use  ServerLockManager.

· A ServerLockManager component must be configured to manage the locks among participating ATG instances.

•          Distributed Caching (caching with cache invalidation events) types of distributed caching are

a.       Distributed TCP caching (uses TCP to broadcast cache invalidation events to all servers )

b.      Distributed JMS caching (uses JMS to broadcast cache invalidation events to all servers )

c.    Distributed hybrid caching (uses Both)

Distributed TCP

                The following requirements apply:

                                Real-time access to item changes

                                Infrequent updates to cached items

                                Modest number of item caches to monitor

Distributed JMS

                The following requirements apply:

                                Reliable delivery of invalidation messages

                                Infrequent updates to cached items

                                Large number of item caches to monitor

Distributed hybrid

                The following requirements apply:

                                Real-time access to item changes

                                Large number of cached items to monitor across many clients

                                Infrequent updates to cached items

By default, the SQL repository uses simple caching. To enable a different cache mode for an item descriptor, set the cache-mode attribute in the <item-descriptor> tag of the repository definition file:

                <item-descriptor name="profile" cache-mode="locked">