Activate Server Cache

The server cache can be activated on the server side to minimize read access to the database. When using the server cache instances are cached in memory for reuse. The server cache can be activated for read and write access. The cache parameters are passed via the server configuration or ini-file (e.g. Server.ini).

Activating the cache requires a [CACHE] variable or section in the configuration or ini-file that is passed when starting the server. In this version it is not possible to define different cache options for involved databases, i.e. the cache is active for all or for none database. This means you must multiply the cache size with the number of involved databases since each database will use its separate cache.

A better strategy would be, of course, running different servers and defining appropriate cache size for each server.

The read cache buffers instances until the maximum cache size is reached. The maximum cache size is passed in megabytes in the SIZE parameter.

SIZE=500 will reserve 500 MB for the cache.

Since the cache is build up dynamically, caching dictionary information will usually not exceed half of the dictionary database size.

When using database cache features, the database can be used by one application, only (e.g. the server). Since not all operating systems guaranty exclusive access to the database an indication is written to the database prohibiting other applications to open the database, the cache lock flag. In case of system crash the cache lock flag remains and the database cannot be opened anymore. To open the database regardless of the state of the cache lock flag you can define

IGNORE_CACHE_LOCK=YES

in the [CACHE] section of the configuration or ini-file.

When the maximum cache size is reached the cache will be reorganized removing entries not used recently. The size of area to be released in the cache can be defined by the RELEASE parameter in the [CACHE] section:

RELEASE=30 will release 30% of the total cache size.

The default is RELEASE=25.

When not using a write cache (write through), modifications are stored immediately to the database. The write cache will hold the instances in the cache writing modifications from the cache in defined time intervals to the database.

The interval in seconds for checking the cache for updates is defined in the CHECK variable in the [CACHE] section:

    CHECK=120 means checking the cache each two minutes.

Default is CHECK=0, i.e. no write cache. High check values will improve the performance but reduce the security since modifications that are stored in the cache only, might be get lost when the system crashes for some reason. Suggested check values are between 60 and 300 seconds.

When writing back the cache to the database there is a risk of serious damage when the system crashes in this phase. In order to avoid this risk, the cache can be written to an intermediate file before being stored to the database. The path for the intermediate file is defined in the INTERMEDIATE variable in the [CACHE] section of the ini-file.

INTERMEDIATE=c:\temp\update.tmp will write updates to c:\temp\update.tmp first.

When the system crashes while creating the intermediate file the modifications in the cache are lost but the database is still consistent. When the system crashes while the data from the cache is stored to the database the database is not consistent but the modifications can be restored from the intermediate file. In this case you must start the server with the same INTERMEDIATE file path. The system automatically detects outstanding update requests and repairs the database before starting the server.

You may request cache statistics. This will slightly decrease the system performance but it allows checking the cache performance. For activating cache statistics

STATISTICS=YES

must be defined in the [CACHE] section.

Sometimes, it it may improve performance for the application activating the cache feature in an local application. In order to activate the cache from within an application program, you must activate the shared database property option for the application (Application::sharedDatabase()) that enables several threads using the same database:

Connection cache is used in order to improve performance for stateless applications (as web applications). Using connection cache requires passing a unique connection string to the server, which allows to identify the client. In this case, access handles on server side are not closed, when the client has performed its task but kept for the next client request.

For using connection cache, the server has to enable connection caching by setting

CACHE.CONNECTIONS=YES

Clients requesting connection caching may set the option variable

CACHE_CONNECTION=YES

or calling cacheConnection() from within the application explicitly. In order to close handles for a cached connection, the client has to disconnect or call Database::forceClose().