locked
No scalability? RRS feed

  • Question

  • Hello,

    I have come across a very big issue in the Sync Services. I constantly get a timeout exception when I try to receive and insert data.

     

    My setup is this:

    I have 3 tables: tblTeam, tblRelation, tblEmployee.

     

    tblTeam contain the names of the different team an employee can be a member of (ex development, research, management etc.).

    tblRelation is a used to create a many-to-many relation between Team and Employee.

    tblEmployee contains the names of the employees in the company.

     

    Its a N-tier application containing a Web Service and a Win32 Client app. The application is using a filter and batching.

     

    Test method 1: +filter, -batch

    I have 5 clients running at the same time against the WS.

    2 clients is trying to receive data.

    3 client is trying to upload data.

    All of them fails with an timeout exception.

     

    It seems to me like the insert command is using a transaction with the isolation level serializable.

     

    Is this really true?

     

    Test method 2: +filter, +batch

    Same setup as test method 1.

    This I can't get to work, because the batch keeps sending the same record in tblTeam which creates an identical index exception in the database.

     

    I have copied your example: batching and applied to my project, but I get the exception as described.

     

    So any thoughts of what I can be doing wrong?

     

    Regards

    Martin

    • Moved by Max Wang_1983 Friday, April 22, 2011 8:54 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Wednesday, January 2, 2008 1:12 PM

Answers

  • Thanks Martin.

     

    could you print out the commands that used for upload and download data? and also profile the server to get some info from the trace ? are you using the default query/lock timeout setting ? with your data chagne size, would it take more than the timeout time to apply the changes ?

     

    there is NO transaction that uses seaializable isolation level during sync time.

     

    Noticed that if all the tables are in the same sync group, in order to ensure data integraty, all changes in that group will be done in one transaction, and hence, the lock on those table will not be released till the changes for the last table are done. this most likely the reason you got timeout.

     

    can you try to snapshot isolation for your upload commands? you can do that in the ApplyingChanges event, the connection and transaction property on the server provider are exposed for such purpose.

     

    thanks

    Yunwen

    Thursday, January 3, 2008 12:42 AM
    Moderator

All replies

  • Thanks Martin.

     

    could you print out the commands that used for upload and download data? and also profile the server to get some info from the trace ? are you using the default query/lock timeout setting ? with your data chagne size, would it take more than the timeout time to apply the changes ?

     

    there is NO transaction that uses seaializable isolation level during sync time.

     

    Noticed that if all the tables are in the same sync group, in order to ensure data integraty, all changes in that group will be done in one transaction, and hence, the lock on those table will not be released till the changes for the last table are done. this most likely the reason you got timeout.

     

    can you try to snapshot isolation for your upload commands? you can do that in the ApplyingChanges event, the connection and transaction property on the server provider are exposed for such purpose.

     

    thanks

    Yunwen

    Thursday, January 3, 2008 12:42 AM
    Moderator
  • Hi Maarts,

           I ran into this same problem. The answer is actually quite easy. Modify the CommandTimeOut property on the Server.SyncAdapter. Setting this to 120 (Two minutes) should do it. You could set it to zero, for infinite, but I would not recommend it. Let me know if you need a code example.

     

     

    Thursday, January 31, 2008 6:36 PM