One of the features of all the versions of the Oracle Utilities Application Framework is its implementation of caching to improve performance.
The idea is simple enough, load data or function into a faster media (e.g. memory) to minimize calls for the data or function on slower media.
Caches are typically in a number of places in an architecture and this is the case for the Oracle Utilities Application Framework based products.
Here is a summary of the various caches and their typical usage in the Oracle Utilities Application Framework:
- Database Level "Most Used Data" Cache - When data is loaded or maniplated by SQL it is loaded into a memory cache from the database data files. It will remain in this cache until the cache needs to make room or after a certain amount of time (to prevent the data becoming "stale"). This cache is automatic and maintained by the Database Management System. There are commands to check the cache contents and even manage the cache manually. Check with the database documentation for details.
- Database level table cache - it is possible to load common "static" data into memory at database startup. Effectively this makes the data memory resident and can be used for high traffic static tables if required. Some DBA's call this "pinning" tables into memory. The database management system manages this information for you but you still have to tell it which data to cache (you usually cache static reference data not transaction data). Check with your database documentation to understand details of commands.
- SQL Cache - When SQL is executed, the SQL statement is cached for the database management system to reuse the statement for future executions. It may be removed from cache on a least reused basis when necessary. In the case of the Framework, we also have a cache of SQL statements within the framework (controlled by spl.runtime.cobol.sql.cache.maxTotalEntries in spl.properties).
- Data Cache on Web Application Server - Common static data, such as metadata, is cached on the Web Application Server. This saves calls to the Business Objects and Database for common reference data. The contents of the cache are controlled via metadata. The cache itself can be controlled using the flush jsp's or JMX client (in OUAF 4). This is controlled using the fieldValuesAge parameter in the web.xml for the Web Application Server.
- Browser Cache - As part of the HTTP 1.1 protocol, an expiry date is placed on all objects that are sent to the browser from the Web Application Server. This is commonly used for HTML and graphics files to keep thm on local cache on the client. New versions of screens and graphics are only transmitted when they expire. This is controlled using the maxAge (text) and maxAageI (images) parameters in the web.xml for the Web Application Server.
Caching is quite important and most of the caches listed here are on
by default in the default installation for the product. In development environments, some developers choose to turn off caching to see the extent of changes instantly but most sites tend to limit the number of development setups so the majority of environments are utilizing caching of data.
While you can tweak the cache settings, most sites use the ones provided as default with the installation of the product with no issue.