This document describes the following aspects of caching behavior as it affects the API:
Objects that are retrieved from the registry by means of the CentraSite API for JAXR are stored in a cache by the JAXR-based connection. All objects stored in the cache are inspected from time to time by the Java garbage collector, which may delete them if there are no references to them from the application.
Any object reference that results from a call to
getRegistryObject(),
getRegistryObjects() or any of the
find methods is, if possible, resolved from the cache.
If an application already holds a reference to an object that resulted from any
of these calls, the reference will also be in the cache, and the call will
return the same Java reference.
There are situations, however, where the cache is cleared completely.
This occurs, for example, after executing saveObjects
or deleteObjects. Any Java reference that is retrieved
after the cache is cleared will be different from a reference that was
retrieved before the cache is cleared.
Note:
This does not affect data integrity, since objects read cannot be
concurrently updated.
The CentraSite user interfaces, i.e. Control and Eclipse, browse JAXR-based data; this means that they make use of the JAXR-based caching mechanism, but they do not block concurrent updates. Control and Eclipse users should be aware that, in general, the data display does not immediately reflect changes that another user may make.
Note:
This does not affect data integrity in the sense that outdated data
may be the source of any updates.
You can see the current data at any time by choosing the button.
The system locally caches dynamically-loaded JAR files. You should be aware that the date and time of the cached files are compared with the date and time of the library files whenever a new connection is created; the JAR files in the cache are refreshed if they are found to be out of date. This could mean that processing continues with a newer version of a JAR file after a connection has been created.
Note also that problems may arise if a custom security manager has been implemented, because the connection to the database will be refused.
The system uses the following strategy to determine the location of the cache store:
If the system property
com.softwareag.centrasite.dynloader.cache-dir is
defined, then its value is used as the location of the cache store.
Otherwise, the location of the cache store is derived from:
A directory whose name is taken from the system property
java.io.tmpdir;
A sub-directory whose name is constructed from the string "CentraSite", a package name, and the string "Jars".
