English - United States  


Usenet Posting #27 - Trigeminal Software, Inc. (English)

Subject: INFO: Sometimes it doesn't pay to be anonymous!
(Originally posted 6/22/01)

Starting with Access 95, Jet (version 3.0) introduced a powerful new technology: replication. Put simply, it allowed you to make 'special copies' of a database such that you could make changes to each copy so that they would differ and then synchronize them so that they would once again be the same. The founding architectural principle is that replicas in the same replica set should be thought of as being 'one synchronization away from being identical.'

At this point, you might want to object that this was not completely true -- after all there are local objects. And then starting with Access 97 came partial replication. But neither of these things affect the basic premise, they simply limit the scope of what will be identical. Even the ability to do one-way synchronizations does not change the premise -- because after a one-way synchronization you were simply one half of a sync away from being identical!

Underlying all of this was an even simpler principle. You see, since every replica is just one sync away from being identical, it means that while each replica in unique, none of them really matters! The only replicas that have any importance are:

  1. The design master, which allows you to make design changes to the replica set that other replicas will pick up on future synchronizations, and is not important until such design changes exist (since in its absence any replica can be promoted to the design master)
  2. Replicas that contain data changes, which are important until they synchronize (after which they are identical again and are not important)

In fact, this is the very principle upon which replica farms are based; since three replicas managed by the same synchronizer are basically identical, Jet can (and does) use arbitrary means to pick a base replica and has no problems changing replicas any time it has problems.

This is what leads to the problem, though. In Jet 4.0 (used by Access 2000 and 2002), two new replica types were created to supplement the 'global replicas' that had always existed:

  • Local Replicas -- replicas that can only synchronize with a particular global replica, which acts as a proxy to the rest of the set;
  • Anonymous Replicas -- A step beyond local replicas, their existence is not even known to the global replica that it syncs with.

(for more information, look for the definition of local and anonymous replicas in the article Database Replication in Microsoft Jet 4.0 by Debra Dove)

If you think of replicas in terms of a family metaphor, then local replicas are children who have never met (and never will meet) their grandparents, and anonymous replicas are children who even their own parents do not remember -- though they will speak to these strangers who identify themselves as long lost children! Now think about this analogy for a moment and you will start to see the first problem with these two replica types with the way that they shatter an important sense of how replication is to work. Although no one should ever be afraid of invalidating one of my metaphors (<g>), one should pause before dropping an important philosophical basis for many replication topologies.

This quickly leads in to the next problem: the local and anonymous replicas are only able to sync with a single replica -- their hub. If their hub fails for some reason, then they are permanently cut off from the replica set, forever. Jet did not provide a method to change the global replica that would act as a proxy, so you cannot (for example) count on a replica farm to help you anymore with synchronization stability. Any time there is a problem and that global replica cannot be reached for a moment, then the poor local or anonymous replica is permanently cut off! And these problems are not uncommon (which is why replica farms are so darn useful!). In any real world replication scenario, this guarantees a degree of fragility for which no customer or user should ever wish.

From here comes the WORST problem: there are numerous cases reported with runtime error 3709, "The search key was not found in any record" (a.k.a. reserved error '-1601') related to local and anonymous replicas. Usually, this is a bug; in fact, Microsoft fixed such a bug without directly reporting the fix in Service Pack 5 of Jet 4.0. However, in other cases it is simply what happens if a hub replica is invalidated, because after that happens, Jet is trying to find the replica to synchronize with after disallowing all replicas! In other words, it is caused by the very design problem that was the cause of this article!

Now, perhaps Jet could do something to fix this: they could support a method to change the global replica that is acting as the proxy for the anonymous or local replica. Unfortunately, Microsoft has stated that there will not be future updates to Jet. So unless that policy changes, then it is not possible to ever see any such change. Also, even if they do decide to release another service pack (and in fairness they did remove the text from Q239114 that stated there would not ever be such an update!), it is unclear whether they will consider this to be a blocking bug that requires a fix, versus a design limitation that cannot be addressed.

Until such a time, the only conclusion that is clear here is that sometimes it does not pay to be anonymous. Heck, sometimes it does not even pay to be local! Jet replication is such a case, for now at least. Don't be tempted by these attractive sounding replica types that really cannot add much beyond misery and frustration to your replication experience.


Problems with this site? Please contact the webmaster@trigeminal.com
with your comments, questions, or suggestions.