Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

The main thing slowing down a lot of applications is all the keyword lookups on the forms. I've written elsewhere about intelligent use of caching in these lookups, but there's another aspect I forgot to mention.

The data in keyword lookup views, in most cases doesn't change very often. But every time you refer to the view in an @DbLookup or @DbColumn, the view indexer still has to check to make sure the view is up to date; every document that's been modified or created since the view was last used has to be compared against the view selection formula to see whether it should be included, even though, as the developer of the application, you know that the answer is probably "no". But there are lots of other documents getting modified in the application all the time, so there are always some that need to be checked. Even if no documents have been modified, it still takes a little time to check that no documents were modified. Hence the delay.

To improve performance of these lookups, it often makes sense to set the view indexing options to not bother to reindex the view every time it's used. The view property box offers an option to re-index "Auto, at most every x hours" where x is a number you specify. Set this to, say, 3 hours, and most of the time the form will work faster because users will not have to wait for the view to re-index. Every three hours (or whatever you specify) the refresh will still happen and might take longer than it would've if the index were being updated all the time. But the average will be lower, and since you often do multiple lookups on a given form, a single user is unlikely to be unfortunate enough to hit the refresh interval on all the lookup views. Especially if you write an agent to run at 6:30 AM and refresh all the lookup views to prevent the early-bird employee getting socked with the whole load. Actually this is not a bad idea to do for other views, either.

When you do edit the keyword documents, you can force a refresh using LotusScript code in the Postopen event of the keyword form. This affects only the replica you're in at the time, but cases where a new keyword value is needed immediately by someone other than the person who created it, are rare, so the indexing delay, added to the usual replication delay, should not be a big deal. Just put some static text on the keyword form reminding the person doing the editing that it may take up to n hours for all users to see the new keyword. If the update is needed by a user on a particular server, they can do the editing on that server (or you can give them a handy button to reach across to another server to refresh its views, if you like).

(Incidentally, setting an index to Manual refresh is probably a bad idea in an application which is not entirely read-only. You can manually refresh the index in one replica when there's a change to the data, but if there are any other replicas, this will not help them).

Andre Guirard | 31 January 2008 07:00:00 AM ET | Plymouth, MN, USA | Comments (8)


1) managing indexing
Charles Robinson | 1/31/2008 11:10:04 AM

"... write an agent to run at 6:30 AM and refresh all the lookup views to prevent the early-bird employee getting socked with the whole load. Actually this is not a bad idea to do for other views, either."

This is probably a basic question, but how would you do this? NotesView.Refresh? The help doesn't say that updates the index, it only "Updates view contents to reflect any updates to the database since the NotesView object was created, or since the last refresh."

2) re: managing indexing
Andre Guirard | 1/31/2008 11:39:00 AM

Yes, I would use NotesView.Refresh. That help description you quoted sure sounds to me like updating the index. How can it display updated documents since the last refresh, if its index still contains old information? It's just that the help was written at a too-basic level, not using the established terminology to refer to aspects of the Notes architecture. It should probably do both, since we have readers of help at different levels of expertise.

3) thanks for the clarification
Charles Robinson | 1/31/2008 12:46:13 PM

I'll confess that I know that NotesView.Refresh updates the index and I was playing devil's advocate. :-) I was mainly doing this to point out that the help is too general to be of any real use. Since it's a back-end class it's not "updating the view contents" -- that sounds like a UI feature by the way -- it's updating the index. It should say something like "Updates the view index to reflect any document changes since the NotesView object was created, or since the index was last refreshed."

4) re: thanks for the clarification
Andre Guirard | 1/31/2008 3:19:27 PM

Sounds good -- why don't you click the feedback link in the help document and pass this on to our documentation folks? That's what I generally do when I have an update to suggest.

5) I keep forgetting about that
Charles Robinson | 2/1/2008 10:27:26 AM

Just did it, thanks for the reminder. :-)

6) Whab about Web applications?
Mael | 2/1/2008 2:54:34 PM

Do @DBLookups in Web apps perform the same way as Notes @DBLookups regarding the view indexer?

7) re: What about Web applications?
Andre Guirard | 2/1/2008 3:32:44 PM

> Do @DBLookups in Web apps perform the same way as Notes @DBLookups regarding the view indexer?

As far as I know, though I suppose the caching (NoCache, ReCache, etc) is different since the browser client obviously doesn't cache the result. Also, the web user doesn't have an action to manually refresh a view if the index is out of date; I'm not sure if web browser views are just automatically refreshed whenever they're used, or whether there's a tricy way to force a refresh, or whether they just can't do that. Anyone know the answer?

8) How about updating views with an agent running after documents added/modified
Scott Leis | 2/5/2008 11:17:52 PM

In the case of a separate keywords database replicated to several servers, it seems to me like a good plan to have an agent that runs on any server after documents are added/modified.

The agent could determine what views to refresh by checking what documents were added/modified. With this method, views would be updated within 30 minutes of any data update on any server, regardless of the refresh interval set on the view properties.

9) re: How about updating views with an agent running after documents added/modified
Andre Guirard | 2/6/2008 8:47:29 AM

Yeah, you could do it that way, though it would work on local replicas only if the user had local background agents enabled. But "docs modified" agents do put something of a drag on the server, and I don't know that it's worth it if the view will get updated in a few hours anyway. I guess it depends on the application. With keyword lists that change seldom, the chances that more than one user is waiting for the change is fairly small.

Another possibility is to add an agent/action (Admin \ Update Lookup Views) so that if someone is in a particular replica and needs the views to be updated, they or the administrator can do that.

 Add a Comment
Comment:  (No HTML - Links will be converted if prefixed http://)
Remember Me?     Cancel

Search this blog 


    About IBM Privacy Contact