Threading and Binding Issues RRS feed

  • Question


    I  had designed the equivalent of MS-sync services for a company I worked for a 3 years ago. The equivalent synchronizer agent class I developed always ran on a background thread created by the class. This was not a timer thread.


    Typically, we bound a datagrid to SQLCE by means of SQLCeResultSet, but we had another means of conveying changes that the synchronizer had made to the local data store. The synchronizer used callbacks that assured that events to identify to notify the client that the row that changed in a table in the dataset bound to the datagrid had changed. This technique had several issues:


    1. We had to ensure that the callback event was on the thread that belonged to the form that owned the datagrid for well-understood issues. Question: What are the threading restrictions, if any, if I decide to put the sync agent on a background thread or timer. Can I do this at all? Obviously the goal is to place the sync process to run in th ebackground and NOT block the UI threads. Are the events I recieve thread-safe in terms of having UI controls handle them?


    2. SQLCeResultSet was a major step towards eliminating the extra memory overhead incurred by the Dataset that my custom sync manager updated after it updated the local data cache. Please describe how MS-sync services deals with this scenario. My end goal is this: I want to bind the various forms controls to some object that sync manager updates, and then be informed what rows in what tables got updated. How is this handled?

    • Moved by Max Wang_1983 Friday, April 22, 2011 8:25 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Friday, March 14, 2008 5:27 PM