Persistent or Temporary Cache ('localDbFile')‌

The local cache database of the DMZ server can either be temporary in the main memory only (default). In this case, the cache is lost in case of a restart of the DMZ server. If the DMZ server is restarted in this scenario and the inner server is unreachable, the DMZ cannot take requests independently.

However, the local cache database can also be stored in the filesystem of the DMZ server persistently. This can be achieved by using the parameter localDbFile, which holds a relative or absolute path to a tablespace file. The file is created at the specified location. If the folder does not exist, it is created automatically.

Using a persistent cache, the DMZ server can access a valid cache after being restarted. In this situation it will be immediately tried to refresh the cache by executing an initial update, but if the inner server can not be reached, the old cache contents remains valid, even if the update failed after the configured maximum of retries.

Caution: If the DMZ server accepts requests independently, they count as received, but they are not processed. It is the urgent responsibility of the user to assure that the inner server is operational in due course. The consigned data is stored as a persistent message until the inner server can receive them. If the lifeTime of the persistent message is over, received data is lost.

The ability of the DMZ server to accept data independently is therefore only fit to bridge gaps during short network failures or maintenance windows.

Caution: Using a persistent cache, the communication parameters are stored in the filesystem of the DMZ server. Using a temporary cache, therefore, protects you much better against unauthorised access of that data. That being said, passwords will be stored encrypted.