Nice thought, not sure of the utility under normal circumstances.
_
The problem is thus: Databases maintain unread marks by NoteID, for efficiency, which means undread marks are unique to each copy of the database, even in a cluster. Server-based replication does NOT hand off the unread marks between the two copies. That is true of both standard server replication and cluster replication. 6.5 offers an option to replicate unread marks in the cluster. As with most Lotus promises relating to unread marks, don't make bets on this.
_
There is one known issue with the 6.5 functionality, and that caveat applies to Kurt's LS/API code as well: it only works if there is a common starting point. If you start swapping unread marks when the counts are already out of sync, it will maintain the same mismatches.
_
So, how do you get unread marks in sync, other than manually unstacking replicas and doing an occasional Alt-E-M-X?
_
The workstation ATTEMPTS to take care of this for you. It maintains a journal of changes to your unread marks. Every time you open a database for which it has the journal, it tries to force all thr journaled changes into the database. The hournal works by UNID, which goes across replica copies, so it theoretically does resycnhronize unread marks among replica copies on your local PC, your primary mail server file, and cluster replicas, and even non-cluster replicas. However, IT ONLY DOES THIS WHEN YOU OPEN THE DATABASE. If you never open the other replica, it never gets updated.
_
So what? If you aren't opening it anyway, what do you care? And when you do open it, won't the synchronization finally take place? Well, yes, but... the journal is limited in size. For a heavy user, it may last a few weeks or even a few days. So, by the time the cluster failover occurs, and the client updates the long-unused spare, lots of unread changes will have dropped out of the jourmal, and the sync does not work.
_
Further, if you use two clients, they will have different journals. If you used one client to read documents A/B/C/D/E and another to read V/W/X/Y/Z,guess what? When failover occurs, the journal will mark the cluster replica's unread count for either A/B/C/D/E but not V/W/X/Y/Z, or vice versa, but never both -- it depends on which PC you did failover on.
Which is why 6.5 offers the cluster unread feature, but as I said, it remains to be seen if it will work.
_
OK, so wouldn't the script library be a good basis for regularly forcing unread exchanges, right? True. But you could accomplish the same thing by forcing a quick UI open of the spare, with the added benefit that the Inbox index will always be primed. I'm not even certain it will be slower -- the script library has to do a merge operation, all based on an interpreted language. What the full open loses in the Inbox open, and read of data/design, you may get back in the speed of the simple jourmal replay, which involves no complex merge or looped script. And with no API calls, safer, too.
_
The code is a nice piece of work of course, I'm just not sure I would go with it.

I can make sense of just about everything except for the field named "sysLessIsLeading" in the System Document. What is it used for and how is it set??? It seems to be used in determining whether to use Server A or Server B in the cluster when trying to perform the synchronization. Are we supposed to write additional code to update this value in the System Document based on results from processing unread marks?
Also, why is the Script Library "ToolsAPIUnread.lss" provided but never referenced in any of the other code? Or rather, why is it provided but the "Use" references in the code are now commented out so that the Script Library never actually gets used?

Login to add your comment