Changes in DirectSmile Integration Server Replication Service

Last week I added a new element called DSMIFileSynchronizer to the service config file. The DSMIFileSynchronizer object is designed especially to synchronize DSMI items from a master server to it’s client servers. Against my first approach to synchronize complete filesystem branches between to servers, this is dedicated to reduce the load and it transfers just the bytes that are relevant to DSMI. The old FileSynchronizer object is still supported though, but I recommend to switch to the new DSMIFileSynchronizer if you need to replicate DSMI user directories.

Here’s how the new Element works:


Every DSMIFileSynchronizer must have a server-  and a client connectionstring and the paths to the dsmusers directories on the server and the client.

When the service is running it checks if items were added, updated or deleted from the master database. If so, the service updates the client.

Because we now rely on the changes made to the database we don’t have to go through millions of files in the filesystems on the server and the client.

By the way, I recommend to configure the synchronizer interval to 600 seconds. This reduces a lot of load as well, and it’s not necessary to check that often for changes.

Please have in mind, that the update cycle and the DSMI cache are two pair of shoes. A fresh uploaded Set can be replicated to the client and be available in the database and filesystem, but not visible in the items browser. That is just because the internal cache of DSMI is refreshed every 25 minutes. That does not mean  that the Set is not available by the interfaces. Even if the Set is not visible in the items browser you can access is already by the set alias. This is because the interface methods don’t trust the cache and can access the database directly if the cache pretends a Set is not available.