The View.AutoUpdate property has been around for a long time. It provides a level of control by the application over how it should react to updates within Notes/Domino views. It can be extremely helpful in applications that have busy views. It also has the ability to be a significant drag on performance in some pathological cases. Recently, certain details on it have evolved in a benign way. It will continue to evolve in the near future.
When the backend is asked to instantiate a View object, the latest updates are retrieved so that they are available when the View collection is iterated. When the View.AutoUpdate is set to "true", the backend is obliged to listen to the View for notifications indicating an update has taken place. If the view is busy, it may have updates many times during the execution of a single backend method, causing all new updates to be requested multiple times. This can be a significant performance problem on a real time application. If the application itself is making updates to the View, the behavior may degrade seriously. This can be less important to an application running under the agent manager, where it runs unattended and during periods of low usage.
If View.AutoUpdate is set to "false," the backend will generally not listen for updates. The View is updated on creation, but updates made within method execution are ignored.
View designs to safely use AutoUpdate = false
Since all Notes/Domino views are dynamic, they can be in constant flux, depending on the application. In the general case, if AutoUpdate is set to "false," incorrect results could be obtained from some methods. For example, the wrong documents could be returned in a result set or newly added documents could be missing.
There are many views where updates are benign by nature and can be safely ignored. If AutoUpdate is set to "true," performance is slowed. In these views, the property should be set to "false" to gain the performance advantage.
Note that the default setting for AutoUpdate is true, to guarantee accurate results under all conditions.
To be a safe yet fast application that makes use of AutoUpdate=false, views should be designed so that updates can be safely ignored. In other words, there should be an implicit guarantee that any updates made during an application will not change the order of the view collection or what appears in the view collection. The best way to do this is to query specially qualified views, in which the view design is sorted on date ascending so that all updates fall at the end of the View. Note that if a view exists in a non-compliant form, a special programmatic view could be created having the desired characteristics for some applications. Alternatively, updates that change the order and set of documents that occur in a view could be queued and delayed until an off time, such as overnight..
When AutoUpdate is important
Recently, some View methods have been upgraded to use new specially designed core services. Under specific situations, the AutoUpdate flag may be set to "true" without adversely affecting performance. Some confusion among the users has resulted. To clarify, the list of methods and conditions where the AutoUpdate property effectively has no meaning is as follows:
|Method||Database access||View.AutoUpdate affects Performance?|
| View.getDocumentByKey|| local (resides on machine running program)|| no|
| View.getDocumentByKey|| remote (resides on another machine, across network)|| yes|
| View.getAllDocumentsByKey|| local (resides on machine running program)|| no|
| View.getAllDocumentsByKey|| remote (resides on another machine, across network)|| yes|
For all other methods that produce or iterate a View collection, whether DocumentCollections or ViewEntryCollection, it may be assumed that the View.AutoUpdate property does affect performance.
Going forward, the table above will evolve. More methods and more conditions will become independent of the AutoUpdate property. These changes will always result in better performance for the application. Behavior will not be affected.