Availability of Authentication Service Through Caching
The Message Authentication Service in a DMZ scenario responds to requests it receives from communication services by forwarding them in a synchronous message to the Authentication Service of the inner server. If the inner server is unreachable, the Message Authentication Service needs to handle requests anyways. For this, it accesses a copy of the database tables of the Authentication Service, which are stored locally. This local database copy is called cache database - or simply cache.
To minimise the risk of using outdated data from the cache, the following caching rules are implemented (see table in section Cache Configuration - Summary).
1. If the inner server responds, the response is used (online mode).
2. If the inner server does not respond, the cache is used (offline mode).
3. The cache is filled during the restart of the DMZ server. All partners, partner channels and certificates are put into cache completely. This procedure is called initial update. It is the same as a full update (7).
4. If an initial update fails, it is repeated every 2 minutes until a configurable amount of retries (maxInitAttempts, default: 12) is reached.
5. During regular operation, the cache is refreshed periodically (updatePeriod, default: 900000 ms = 15 min) using a partial update. In the process, only the record sets that changed are being updated. Record sets marked as deleted are also marked as deleted in the cache. Record sets that have been deleted physically remain in cache. Because of this, a periodical full update is necessary. Changes are broadcasted from the inner IS to all DMZ Message Authentication Services (push).
6. As soon as the Message Authentication Service of the DMZ successfully accessed the inner Authentication Service by Message, a syncRequired mark is set in the response message if the inner Authentication Service has modified data, the DMZ has not replicated yet. The DMZ then starts an immediate replication. The update period starts again after that. Using the configuration parameter ignoreNotification, this feature can be switched off.
7. In a full update (see below), first a check is executed if the inner server is reachable. If not, cache data remains untouched. If the inner server was reachable, the cache is purged completely and all partner data, partner channels and certificates are restored. If the restricted caching by channel types (cachedChannelTypes ) is configured, only allowed types are cached. Partners that do not have channels of an allowed type are not replicated.
During the time between deleting old data and complete storage of the new data, the cache is invalid. Requests of the communication services that appear in this phase and can not immediately be handled by the inner server are temporarily postponed. After a configurable timeout (cacheUpdateTimeout, default=8000ms) those requests fail with an exception if the update has not finished in the meantime. This situation can only occur if the network collapses during a full update and a request to the communication layer appears simultaneously.
Requests in online mode (inner server is reachable) are always handled by the inner server, even if a full update is executed.
The full update is not executed in offline mode so requests are handled from the unchanged cache. Only the situation of a collapsed network during a full update is critical. However, failures shorter than cacheUpdateTimeout will be handled.
8. The following cases will trigger a full update:
If the DMZ server was started (initial update, means full update with retry).
If the inner Authentication Service was restarted.
If the fullUpdatePeriod has passed.
The first update of a day is always a full update.
9. If the next update (due to a rule in item 8) needs to be a full one, but the inner server was not reachable, no immediate retry is executed (retry only on initial update). Instead, the update is cancelled. The next scheduled update will be a full update then.
10. If the inner server (or its Authentication Service) is restarted in a DMZ cluster, the next update is scheduled as a full one.
11. If in a DMZ cluster one DMZ server is restarted, its next update is scheduled as a full update. The other DMZ servers follow their own rules.