Synchronizing Attributes

Articles and Tips: qna

01 Sep 2001

Dear Ab-end: Over time, at least two attributes have been created by Schemax and added to my Novell Directory Services tree. These attributes are not set to Synchronize immediately. I went through the tree to check the attribute flags of the other attributes in the tree.

It appears as if the base NDS attributes are set to synchronize immediately, the ZENworks attributes are not, the Novonyx ones are, the BorderManager ones are not, etc. It seems to me that the different product groups each chose on their own what attribute flags to use for their attributes.

Is it a problem to have an attribute not set to synchronize immediately? If an attribute is not set in this way, what triggers the synchronizations of any changes?

There may be a problem with these attributes as evidenced by problems in a program that is trying to access them. However, the problem may very well lie elsewhere. I think that I will be able to delete and then recreate the attributes via the LDAP APIs, but would rather not if it is not necessary. What's Up? -- Synchronizing Solitude in Saratoga Springs

Dear Synchronizing: According to the guru of NDS Synchronization on Novell's NDS Development Team, the following is true:

If an attribute is flagged Sync Immediate, then when it is modified, the synchronization process is scheduled to run within 10 seconds. This does not necessarily guarantee that the attribute will be "immediately" sent to all other replicas, but the process does start. If there are other circumstances preventing or delaying successful synchronization, the attribute will take some time (depending on the specific circumstance) before being fully synchronized.
If an attribute is not flagged Sync Immediate, then when it is modified, it schedules the synchronization process to run in 30 minutes or less. When the synchronization process is initiated, all changes within a given partition will be synchronized, so if 10 attributes are modified and only one is set to Sync Immediate, they will all go when that one does.
NDS is a "loosely-consistent" database. It is possible and regularly happens that an object or attribute is modified on server-1 and then shortly after that the object or attribute is read from server-2 and the change has not yet been synchronized there. NDS-aware software must take this possibility into account. However, if you modify something on server-1 and read it back again from server-1, you should always get the newly updated information.

In addition there are a few more things to consider when weighing sync immediate versus waiting for the batch sync. You may consider:

Attribute Size. If the attribute is large, you may want to wait on the synchronization process, unless you expect the data to not change often, in which case it doesn't hurt to set synchronize immediately.
Change Rate. If the attribute is likely to change repeatedly during an operation, you may want to wait.
Criticality of Correctness. If the program acting on the data is affected by the data being out of date, you should go ahead and synchronize immediately. However, if up-to-date data is VITAL to the program, you may want to go a step further by setting the CONFIDENCE level on the context handle to HIGH.

This will cause the program to always use the master replica for both read and write. Of course you lose redundancy when you do this, but you are assured of data correctness and you still have replication of the data in case of catastrophe.

Thanks to the System Engineers News Group, Novell Technical Support and Novell NDS Engineering for contributing to this column.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.