ATG Repository

Main terms in ATG Repository

Cache Modes - 

Simple Cache - handles caches in each server locally; no attempt is made to synchronize updates across multiple server instances.This mode is suitable for read-only repositories such as product catalogs.

Locked Cache - uses read and write locks to synchronize access to items stored by multiple 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—for example, Commerce order items, which can be updated by customers on an external-facing server and by customer service agents on an internal-facing server. By restricting write access, locked caching ensures a consistent view of cached data among all ATG instances.

         Locked caching has the following prerequisites:
  •  query-cache-size attribute to 0.
  • The repository’s lockManager property is set to a component of type ClientLockManager.
  • At least one ClientLockManager component on each ATG instance must be configured to use ServerLockManager.
  • A ServerLockManager component must be configured to manage the locks among participating ATG instances.
Distributed Cache - uses TCP/ JMS to broadcast cache invalidation events to all servers in a cluster.

       Setting Cache Mode - 
             <item-descriptor name="user" cache-mode="simple">
    By Default cache mode is Simple. You an also disable the cache by setting cache-mode="disable"

Cache Types -

Item Cache -
    Item cache used to capture all the repository items , indexed by repository IDs.
        Default size : 1000

Query cache -
    Query cache holds only the repository ids of items.
        Default size : 0
    We can set query cache size 1000 or higher. Because it only contains the query parameter and string Id. It will not consume much memories.

Helpful example from Oracle ATG Doc to determine item Cache Size -

Creating new repository - 

  • *
definitionFiles=/*path*/*Repository.xml (Repository Name)
  • *Repository.xml -
<?xml version="1.0" encoding="UTF-8"?>
<item-descriptor name="" display-name="" >
<table name="" type="primary" id-column-name="">
<property name="userId" column-name="user_id" data-type="String" display-name="user id"  required="true"/>

Issue : Base Catalog not loading or base catalog is empty.

Description : After server start nothing is loaded into site. After checking the product catalog, finding no base catalog has been uploaded. In other word when we list all items for Catalog, It doesn't have any data.

Solution : Check the BCC instance and verify whether Catalog has been uploaded or not. If you are able to find the catalog in BCC. Then it is an issue with non versioned database. Hence BCC retrieving data from versioned schema and Commerce from non versioned. 
    Deploy a project in BCC with some change in Catalog and deploy it. Run CatalogMaintainceService and issue will resolve. Revert the changes from BCC. Do the same for all other missing categories and products.
    If issue is in staging or development environments, we can do sync data from production to resolve this issue.

Lock Management :

           Lock servers synchronize cache among ATG servers to maintain data integrity.

Server Lock Manager : End-User/customer facing servers

  • Modify <ATG9dir>/home/localconfig/atg/dynamo/service/

  • #


Client Lock Manager : Agent facing servers

  • Agent-facing servers use the customer-facing server lock manager for any shared repositories, and individually scheduled services.
  • The agent-facing clusters define a ClientLockManager_production, which points to the ServerLockManager.
    • # /atg/dynamo/service/