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 server cannot take requests independently.

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

If using a persistent cache, the DMZ server can access a valid cache after being restarted. In this situation, an immediate attempt is made to refresh the cache with an initial update, but if the inner server is not accessible, the old cache content remains valid, even if the update attempts are abandoned after reaching the maximum number.

Caution: If the DMZ server accepts requests independently, they count as received, but they are not processed. It is the responsibility of the user to assure that the inner server is operational in due course. The sent data is stored as a persistent message until the inner server can receive them. If the lifeTime of the persistent message is over, the 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: If a persistent cache is used, the communication parameters are stored in the file system of the DMZ server. Using a temporary cache, therefore, protects you much better against unauthorised access of this data. However, the passwords are stored encrypted in any case.