Replication

About Replication

Sites and locations enhance checkin, checkout, and open for view or edit performance for clients that require WAN access to a centralized storage location. The central store (default) is mirrored to one or more remote machines (locations). In this way, a client at the remote site has LAN access to the data.

When a user performs a file checkin, the system writes the file to that user's preferred location. If the preferred location is not specified, the system writes the file to the store's default path. In the schema, the business object is marked as having a file checked in at this location. When another user requests the file for checkout, the system attempts the checkout from these locations in this order:

• Locations that are part of the checkout person's preferred site. If none of these locations contain the newest copy, then:
• The store's default location. If this does not contain the newest copy, then:
• Any location that contains a valid copy of the file. This means that the system performs a sync-on-demand: the system copies the requested file to the user's preferred location and then performs the local file checkout.

For example, if you are in the United States and you have an office in Boston, and another in Paris, you could have two FCSs: one in both offices. If replication is used, it does not matter where the checkout occurs because the FCS ensures that both locations are synched up and ensures that duplicates are removed.

A user can only have one site. A site can have one or more locations. A functional store contains one or more locations. For example, suppose that:

• The user is located in Boston, so Site = Boston.
• There are 2 possible Locations: Boston and Paris.
• There are 3 possible functional Stores: Marketing, Sales, and Engineering.

For example, if the user in the example is an engineer who works in Boston, the Site would be Boston, the Store could be Engineering, and the Location could be Paris or Boston. To switch the default location, use the locationOverride switch.

When the system needs to replicate multiple files, the process is streamlined by replicating files in a single batch rather than one at a time. The system determines the list of files to be replicated and then groups them by "destination location." Files in the list can have different destination locations as long as they all have the same FCS URL, since the FCS URL for the first group of files is used for the checkout ticket. The system then replicates each group of files to the destination location in a single batch, and commits the metadata. If a replication process fails, subsequent items will not be committed but all previously committed items will remain present in the database.

A checkout operation with replication looks like this:

If a transaction fails, the 3DSpace Service goes back and deletes the files on the remote server. If there are duplicates, the 3DSpace Service deletes the duplicates that are on the server that is logically part of the FCS server.

If there is more than one FCS server, the 3DSpace Service cleans up the copy of the file where it was last checked in. All other copies are marked obsolete. In addition, you can write a cron job to do the tidystore cleanup operation.

Replication from a Specific Source and Destination Location

With FCS file replication, the source location is the first location that has the current file. The destination location is the requesting client's preferred location. However, you can execute a custom replication program to override this default behavior. This program must be defined on the store; then any location involved in replication with this store will use this program. Defining a program on a store allows for greater control over when the program is executed. The custom program must implement the following Java interface:

package com.matrixone.fcs.mcs;

import java.util.ArrayList;

import matrix.db.BusinessObjectProxy;

import matrix.db.Context;

/**

* This interface governs a class that can be used to effect the behavior during replication

*/

public interface ReplicationTrigger {

/**

* Called prior to replication.

* @param cntx context

* @param mcsURL URL of the MCS, can be null if unknown

* @param inList - list of @see {@link BusinessObjectProxy} that represent the source for file that need replication

* @param copyList - list of @see {@link BusinessObjectProxy} that represent the destination for file that need replication

* @return replacement inList, can be the original inList

* @throws Exception

*/

public ArrayList<BusinessObjectProxy> check(Context cntx,

String mcsURL,

ArrayList<BusinessObjectProxy> inList,

ArrayList<BusinessObjectProxy> copyList) throws Exception;

}

To define the custom replication program on the store, execute the following in MQL:

Replication Through Stores

In certain cases, it may be beneficial to replicate files from a location through a central store. To enable this functionality, configure the following class on the store in MQL:

Single File Replication Optional Behavior Change

It's now possible to change the current on demand replication behavior upon checkout operation.

This optional behavior change provides the ability to disable on demand replication upon single file checkout request.

Upon a single file download operation, the server checks if the file is available on the user’s preferred location. If that is the case the user downloads the file from that location. The behavior change occurs if the file is not available on the user's preferred location:

• The user downloads the file from the STORE (central site) if possible.
• If not, the user downloads the file from the first available location.

The following system settings can be used to enable or disable the behavior change:

To enable:

To disable:

Default value is off.

File downloads through FCS media URL (dynamicImage) are included in this behavior change.

Single file checkouts done through mql checkout bus command are not included in this behavior change.

This optional behavior change applies only for single file replication downloads.

The behavior change may impact network bandwidth consumption since you may have simultaneous file downloads where users were waiting on file to be replicated first. The download speed will vary if the file is not available on the user's preferred location depending on the network latency, available bandwidth and source site performance.

No Synchronization On Copy

The behavior at copy time has been modified to avoid triggering file replication as far as possible. With the new default behavior, files are no longer replicated when doing a copy, unless explicitly asked for (store/location override).

If for some reason an administrator wants to restore previous behavior, it will still be possible to disable the system setting as follows:

set system fcssettings nosynconcopy Off;