Light at the End of the Tunnel, or an Oncoming Train?

Release 4.0 of Notes will handle replication in new, but not necessarily predictable, ways

FIELD-LEVEL REPLICATION

In the current version of Notes, any change to a document in a database causes the entire document to be copied to replicas of the database during the next replication. R4 will offer more granularity, so only modified fields will be copied.

Look for: Faster replication than R3 for some databases. The best candidates for improvement are large-document databases in which most changes involve updates to small fields in existing documents. An example would be a training database in whic h each document has a video portion and a list that adds your name to it once you've viewed the document. Only the list of names will be copied during replication in R4.

Look out for: Increased overhead and longer replication times for other databases. R4 may take longer to replicate databases made up of documents that contain many small fields. For a server to determine which fields of a document need to be replicated, the bookkeeping of updates must be handled for each individual field rather than just for whole documents. Moreover, even after a server has identified modified fields, updating each of them individually would probably consume more time than simply overwriting the entire document.

MULTITHREADED REPLICATORS

In the existing version of Notes, a server's replicator process can pull updates from only one other server at a time. R4 servers will be able to run several simultaneous replicators.

Look for: Les s severe consequences of occasional extraordinarily long replications. In a hub-and-spoke replication topology, for example, the hub's replicator can often be the constraining bottleneck. Any unusually long pull (due to a slow connection or a large number of updates at the spoke) ties up the hub's replicator and causes delays in the initiation of subsequent replications by the hub. In severe cases, subsequent replications are simply missed. An R4 server will be able to spawn additional replicator processes as necessary and thereby perform simultaneous pulls.

Look out for: CPU overload, database-engine overload, and database corruption. The replicator is a CPU-intensive process. Several replicators running at once could seriously bog down the server. Several replicators simultaneously updating large numbers of documents could bog down the database engine, and serious problems could arise when several replicators try to simultaneously update the same database, or--worse yet--the same document.

UPDATE IDENTIFICATION

In R4, servers will apparently be able to identify much more rapidly those situations in which there are no new updates to be pulled.

Look for: Less overhead associated with initiation of replications. This improvement will make it less risky to schedule frequent replications. (It should help prevent problems of the type described in the article "Optimizing Notes Replication," September 1994 BYTE.)

Look out for: Nothing.