Sync Framework - Inefficient ApplyChanges

argot — Tue, 27 Oct 2009 05:54:08 GMT

for the ado database sync, the method

public virtual SyncContext ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet,SyncSession syncSession)

on server side is not efficient, as it receive the changed data from client side, but it again sent it back to client within the SyncContext.

In the returned SyncContext object, I found DataSet and GroupProgress.Changes is almost the same as input dataset. by verifying the code inside sync framework, I found:

internal SyncGroupMetadata ResetProivderState(SyncGroupMetadata groupMetadata, DataSet dataSet)
{
    this._rawOldAnchor = null;
    this._rawNewAnchor = null;
    this._rawMaxAnchor = null;
    this._syncContext = new SyncContext();
    this._syncContext.DataSet = dataSet;
    SyncGroupMetadata metadata = this.GenerateOrderedGroupMetadata(groupMetadata);
    this._syncContext.GroupProgress = new SyncGroupProgress(metadata, dataSet);
    return metadata;
}

so I use the code below:

SyncContext context = _serverSyncProvider.ApplyChanges(groupMetadata, dataSet, syncSession);
context.DataSet = null;
context.GroupProgress.Changes.Clear();
return context;

to make the size smaller.

Sync Framework Common Practise of ADO.NET

argot — Sun, 18 Oct 2009 13:30:37 GMT

I have been working on database synchronization for a couple of weeks, and seems it at the final testing stage, I am using Microsoft Sync Framework 2.0, the DB server is SQL server 2008 Standard, and clients are SQL Server 2008 Express as I use Change Tracking to track DB changes instead of TombStone Tables and Guid tracking columns, I use WCF+IIS+SSL to host server side service, the binding uses Gzip binary encoding.

The reason we are not using SQL Server Replication is because our tables need dynamic filters and some of them logic is quite complicated (we need to download the certain data to client according to the client name and setting), so when Replication try to generate the snapshot, it takes quite long time and CPU usage is quite high.

Coding didn't take me so long to finish (main part is write customized filter queries) but I realize some of the sync tables using bigint as primary key instead of Guid, so I have to assign a new seed to each client to avoid confliction. This new seed number will download and apply when clients reinitialize after schema download and applied.

Also, I found after "Applychanges" has been called, some tables identities will be changed, because in the "InsertCommand" of the Adaptor, using "SET IDENTITY_INSERT [tableName] ON", this will cause "If the value inserted is larger than the current identity value for the table, SQL Server automatically uses the new inserted value as the current identity value.", so we use a new table to hold the current identity for tables before applychanges and set it back after applychanges.

I have found when uploading changes to server side, the dataset contains all changed data, and after ApplyChanges called, the return object SyncContext still contains the dataset which sent to server, this is very inefficient, also when some changes apply failed, the return size grows very big because the GroupProgress inside SyncContext contains all dataset info plus failed table and row info, this makes memory growing very fast on server side as well as transferring.

Server side need to maintain a session as the the clients call is each client based, so the WCF interface is like this:

[ServiceContract(SessionMode = SessionMode.Required)]
    public interface IServiceForSync
    {
        [OperationContract(IsInitiating = true)]
        bool InitialiseSetting();

[OperationContract(IsInitiating = false)]
SyncContext ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession syncSession);

[OperationContract(IsInitiating = false)]
SyncContext GetChanges(SyncGroupMetadata groupMetadata, SyncSession syncSession);

[OperationContract(IsInitiating = false)]
SyncSchema GetSchema(Collection<string> tableNames, SyncSession syncSession);

[OperationContract(IsInitiating = false)]
SyncServerInfo GetServerInfo(SyncSession syncSession);

[OperationContract(IsInitiating = false)]
SyncInfo GetSyncInfo(string SyncHostName, long rpuid);

[OperationContract(IsInitiating = false)]
List<String> GetInitSchema();

[OperationContract(IsInitiating = false)]
List<String> GetUpdateSchema(string SyncHostName);

[OperationContract(IsInitiating = false)]
bool ResetStatus(string SyncHostName);

        [OperationContract(IsTerminating = true)]
        void EndSession();
    }

The Service side binding in the web.config is like this:

On client side the remoteServer of the syncAgent will be the proxy, and I use one SyncGroup as any exception happens, it will reverse back to original.

public class SqlExpressClientSyncProvider : ClientSyncProvider

and in the ApplyChanges of the ClientSyncProvider, we need to Map SyncDirection from client point of view to our internal server point of view, so part of code is like:

foreach (var tableMetadata in groupMetadata.TablesMetadata)
            {
                switch (tableMetadata.SyncDirection)
                {
                    case SyncDirection.Snapshot:
                    case SyncDirection.DownloadOnly:
                        tableMetadata.SyncDirection = SyncDirection.UploadOnly;
                        break;
                    case SyncDirection.UploadOnly:
                        tableMetadata.SyncDirection = SyncDirection.DownloadOnly;
                        break;
                }
            }

in GetChanges, we need to swap anchors:

public override SyncContext GetChanges(SyncGroupMetadata groupMetadata, SyncSession syncSession)
        {
            // neet to set the LastReceivedAnchor as the LastSentAnchor since
            // DbServerSyncProvider operates from the server's perspective, so
            // we swap the two fields temporarily.
            foreach (var metaTable in groupMetadata.TablesMetadata)
            {
                var temp = metaTable.LastReceivedAnchor;
                metaTable.LastReceivedAnchor = metaTable.LastSentAnchor;
                metaTable.LastSentAnchor = temp;
            }

            var context = _dbSyncProvider.GetChanges(groupMetadata, syncSession);

            if (_bEnableTimeAdjusting.HasValue && _bEnableTimeAdjusting.Value)
                AdjustDSTimeZone(context.DataSet, "CLIENT"); //-TN - adjust all datetime columns before sync.
            //swap them back for consistency
            foreach (var metaTable in groupMetadata.TablesMetadata)
            {
                var temp = metaTable.LastReceivedAnchor;
                metaTable.LastReceivedAnchor = metaTable.LastSentAnchor;
                metaTable.LastSentAnchor = temp;
            }
            return context;
        }