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).