What is Jet Replication?

From Jet Replication Wiki -- Microsoft Office Access Replication

Jump to: navigation, search

Jet Replication is a technology included in Microsoft Office Access that allows one to edit a Jet database in two locations and transparently merge the changes through a synchronization. As a way of explaining what Jet replication accomplishes, Michael Kaplan always said:

Any two replicas in a replica set are only one synchronization away from being identical.

So far as I know, Jet is the only non-server-based database engine that supports replication in any form. Most server database engines support one or both of the two main classes of replication, Master/Slave and Multi-Master.

Contents

Master/Slave Replication

Master/Slave replication is usually used to improve concurrency, such as in a website with many read-only users. Updates are applied to the master and propagated to the slaves (usually view transaction log shipping, where the transaction log from the master database is run againt the slave databases). These slave databases make it possible for a heavily used website to support more users, since requests for data reads can be transparently served by any of the slave replicas. Master/Slave replication is also used for emergency recovery, such as the case where a slave database is maintained offsite so that in the event of failure of the main database, the application can fall over to the slave. There is nothing really analogous to the Master/Slave type of replication in Jet replication as there's no structural method for denying edits at any of the replicas (though there is a Prevent Deletes replica type in Jet 4 -- see the Jet 4 White Paper for a discussion of Prevent Deletes replicas). Second, since Jet has no transaction logs, there is no mechanism for communicating transactions on a master database to the slaves.

Multi-Master Replication

Multi-Master replication is what Jet implements, where edits can be applied to any replicas and then synchronized. Server database replication can be implemented either as synchronous (eager) replication, where changes are not committed in any replica without checking with all other replicas, or asynchronous (lazy) replication, where changes are committed and then conflicts between data edits in different replicase resolved later.

Asynchronous Replication and Conflict Resolution

Jet implements only asynchronous replication and provides for conflict resolution after the fact. When edits in two replicas conflict, one of the edits wins and is committed in both replicas, and the losing edit is recorded in a conflict table. When conflicts are resolved, the user is presented with both the winning and losing data. The default rules by which Jet resolves a conflict are complicated and differ greatly between Jet 3.x and Jet 4. In Jet 3.x, conflicts occurred at the record level, whereas Jet 4 offers column-level conflict resolution. What this means is that in Jet 3.x, changes to field1 in record1 in replica1 would cause a conflict when field2 in record1 in replica2 is edited. In Jet 4, this would not cause a conflict at all -- the edit to field1 would be merged with the edit to field2, producing no conflict.

More Details About Jet Replication

For a detailed discussion of the specifics of Jet replication and Jet's default conflict resolution rules, see the Jet 4 White Paper.

Personal tools