Cache Administration Parameters

General Settings

Record Statistics

You can stipulate whether or not cache statistics are recorded.

Every time a query is executed, statistics are recorded for every cache element. These include:

• The user who created an element by executing the query,

• When it was created,

• The user who changed an entry,

• When it was changed,

• The last user who had read access to an entry,

• When the read access was made,

• The number of read accesses.

Writing the statistics involves additional access to the database, which can have an negative effect on performance. It is therefore possible to deactivate the statistics function.

In the default setting it is activated. In the default setting, the statistics are buffered and are not completely written to the database fully until a query navigation step is completed. System performance is then considerably better than when writing each individual data record to the database. See the administration parameter Deactivate Statistics Buffering .

Deactivate Statistics Buffering

You can decide whether or cache statistics are recorded and buffered.

Statistics can be written for access to cache elements. To avoid a negative impact on performance, all statistics for the runtime of a navigation step of a query are gathered and are only written to the database once the navigation step has been completed.

For error analysis purposes however, it is sometimes better not to gather the entries, but to write them to the database directly every time instead. For performance reasons, this should be the exception rather than the rule however.

Monitor Should Read All Data Initally

You can stipulate whether or not the cache monitor reads all cache elements initially.

For performance reasons, the default setting is for the cache monitor to only read and display the entries at query level. Lower-level are only read if a user chooses to view them. If this parameter is set, the system reads all entries at once when the data is initially loaded.

This setting is only relevant for cache mode Query Aggregate .

Cache Logging Activated

You can activate and deactive cache logging.

To support more detailed analysis of errors, logging functions have been integrated into the cache. This makes it possible to collect information about data written to and read from the cache. If errors occur, this parameter can be used to activate or deactivate logging.

Use Old Cache

Cache mode Query Aggregate replaces previous cache modes 2-4. To maintain compatibility however, it is still possible to switch between the new cache mode and the old ones.

Settings for Old Cache

Deactivate Read Statistics for Old Cache

You can deactivate writing of read statistics from the old cache modes and thus reduce the risk of inconsistencies arising when writing cache entries in the old cache modes.

This parameter only affects the persistence modes flatfile (both application server dependent and cross application server), cluster table and transparent table (BLOB).

Terminate If No Enqueue Received

The cache repeatedly attempts to set an enqueue so that it can work with a cache entry. If a process cannot set the enqueue after a certain number of attempts (after 1000 attempts for example), the system assumes that there is a problem. To make the user aware of the problem and to avoid inconsistencies, the cache terminates the current process with an error message (x message).

An administrator can set the number of attempts made to set the enqueue. If you set the number of attempts too low, you cannot properly assume failure given the small number of unsuccessful attempts, as setting the number higher could have resulted in the cache being able to set the enqueue. As an administrator you can then use this parameter to stipulate that the prozess - the query that is - will not terminate with an x message, but will continue instead, even if the cache could not set the enqueue.

This parameter only affects the persistence modes flatfile (both application server dependent and cross application server), cluster table and transparent table (BLOB).

Settings for New Cache

Store Data of This Size and Greater in Larger Persistence

The new cache mode Query Aggregate uses a cluster table and BLOB storage (table with XSTRING area) to store cache entries with query data. This setting specifies the size limit up to which the system should write to the memory area for smaller query results and after which it should use the memory area for larger data.

Using the following two settings, you can specify which memory area should be used for query results larger than the key figure specified here.

You specify which memory area to use when creating the cache entry for the query data. Note that this value cannot subsequently be changed, even if the cache entry subsequently becomes larger than the predefined key figure.

BLOB Table for Large Amounts of Data

If this option is selected, cache entries with query data that exceeds the predefined size limit when initially created are written to the BLOB table (table with XSTRING). It is better to use BLOB tables when transporting larger data volumes between the database and application server. It is not possible to save internal tables however, which also means that it is not possible to export data to an internal table instead of an XSTRING, which would actually offer better performance under some circumstances if it were possible.

Cluster Table for Large Amounts of Data

If this option is selected, cache entries with query data that exceeds the predefined size limit when initially created are written to the cluster table (also known as the index table). There is no advantage in using cluster tables when transporting larger data volumes between the database and application server, as this requires multiple implicit SELECT statements. This does make it possible to save internal tables however, which offers better performance than exporting data to an XSTRING under some circumstances.