Unread Mark problems in clustered environments
Unread marks are not automatically updated across replica databases. Therefore, in a clustered environment, replica databases do not get updated with unread mark activity until directly opened by the Notes client.
In Notes/Domino 6.0.3 and 6.5, additional functionality has been introduced to provide replication of unread marks.
Note: In order for this feature to function, both the servers and clients must be running at least 6.0.3 or 6.5. The feature is enabled via an Advanced Database property. The "Replicate unread marks" property can be enabled for "Clustered servers only", "All servers" or the default "Never".
Note: In order to enable the feature for local replicas select the "All servers" option. For additional details on the use of this new functionality and how it functions refer to the following document:
"Setup and Details on the Enhanced Unread Functionality Introduced in Notes/Domino 6.0.3 and 6.5" (# 1140018).
In previous releases and/or cases where the unread replication feature is not enabled, databases rely on the Unread Mark Journal in the client's CACHE.DSK file to update any replicas with recent client activity.
The Unread Mark Journal updates any replicas opened on servers different from the original on which the actual activity took place. This means that the Journal does not update a server database with the same activity that already took place on that server. This can lead to lost unread mark activity when a server crashes.
When failover or load balancing occurs and the replica database is opened, the Unread Mark Journal writes all recent activity for the current ID to the Unread Mark table. Unread Marks should appear as expected at this point. This table is then written to the database when all connections for the ID are closed.
However, when the original server crashed, the Unread Mark table may not have been properly written to the database, and recent activity is lost. When the original server is running again, the client opens the database and sees unread mark activity that took place on the failover server (due to the Journaling). However, activity that occurred the last time the database was open on the current server was not written to the database - and is not written back by the Journal. This is because the Unread Mark Journal has already interpreted proper update of the unread mark table the last time this database was open.
The result is that unread marks are lost only for the previous session on the server that crashed. Since the Journaling does not update the original database with the original unread mark activity, and the Unread mark table was not properly written to the database due to the crash, the unread marks are lost for that session. However, the unread mark activity for the session that was opened on the failover server appears as expected due to the local Journaling.
|Messaging Applications||Lotus End of Support Products||Lotus Domino||7.0, 6.5, 6.0, 5.0|
Lotus Notes Client