Caching Considerations
This section describes various aspects of caching behavior as it affects the API.
JAXR-based Caching Strategy
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 is present in the cache, and the call returns 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 is 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. |
Caching in User Interfaces
The CentraSite user interfaces, that is, Control, Business UI, 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, Business UI, 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 clicking the Refresh button.
Dynamically Loaded JAR Files
CentraSite 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: | Problems may arise if a custom security manager has been implemented, because the connection to the database is refused. |
Cache Location
CentraSite 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:
1. A directory whose name is taken from the system property java.io.tmpdir.
2. A sub-directory whose name is constructed from the string CentraSite, a package name, and the string Jars.
