Container Caching during loads.

While loading a container graph using the concept of scope, it is possible to reload the same container twice. In order to save time to load those repeated containers, a caching mechanism has been implemented during load operation.

How the cache is stored

Every time a container is created by a manager, the match container method is called. This method will check in the cache to see if the container exists based on the primary key. If the container already exists, then the container is reused for the rest of the operation. If it doesn't, then the new container is added to the cache.

The cache stores a map of all the previously loaded containers using a unique String key. This key is composed of the short manager name with the primary key values.

For instance, the primary key of a WBS Task with ELEMENT_ID = 1234567890ABCDEF will be :

    wbsmanager1234567890ABCDEF

The container cache also stores a list of all the scopes that were used to load the element. So, if the same RPMObject was loaded twice with 2 different scopes, then the cache will remember this fact.

How a container is loaded from the cache

The cache is only used during the loadByPrimaryKey operation in managers. At that point, the manager will try to see if the container was already loaded in the cache with the same scope that is currently being requested. If the scope is null, then a cache hit will occur as soon as the container is within the cache.

Sample Benefits

In a sample report that was built that queried around 900 scope elements, the number of select statements executed on the DB went from 30,000 calls to around 5,000 calls. It has a major impact on the database load and network traffic.

Side effects of the cache

Certain objects aren't handled correctly with caching. (for example, documents because the same element can be reused in many parents).