none
[MS-GRVDYNM] How undo delta works? RRS feed

  • Question

  • [MS-GRVDYNM] document mentions when an undo of delta should be done and why. It is mentioned in sections

    1.3.1 Synchronization

    3.1.5.2.4 Delta Execution

    I would like to understand the behaviour of Undo in the following example. If there is a record with field 'name' set to 'X'. Now there is a message M1 which is 'Set Field' message as specified in section 3.1.5.4 of [MS-GRVRDB] and it changes the 'name' filed to value 'Y'.

    Now when Dynamics wants to undo the me above message, how does it know what value the field is supposed to be?

    I hope I am clear in my question, if know please let me know.

     

    Saturday, March 26, 2011 12:59 PM

Answers

  • Hi Rajesh,

    Dynamics itself does not know what the value of the field is supposed to be when informing its client (RDB in the example below); it only knows that the current value needs to be undone in order to coalesce the changes from one or more endpoints.  Storage of the previous value of the field is an implementation detail of the client, in this case RDB.  RDB stores the previous value for fields on executing each 'Set Field' command, reapplying them as the current value when instructed by Dynamics to Undo. This Do/Undo behavior works the same way for all the commands documented in  MS-GRVRDB - Add Record, Add Records, Delete Record, and Set Field, with only Set Field needing to store a previous value (the Undo of the other commands just reverses the operation).

    Best regards,
    Tom Jebo
    Escalation Engineer
    Microsoft Open Specifications

    Wednesday, April 6, 2011 4:34 PM
  • Hi Rajesh,

    The key to deciding whether a delta has been processed on all endpoints is the Delta Ack message.  See sections 2.2.2, 3.1.5.2.6, and 3.1.5.4 for details.  The implementor will need to store Delta Ack messages and process them - once they have received a Delta Ack from each of the other endpoints for a particular delta they will know that the particular delta has been processed on all endpoints.  See section 4.5 for an example of delta message processing.

    Best regards,
    Tom Jebo
    Escalation Engineer
    Microsoft Open Specifications

    Monday, April 11, 2011 6:16 PM

All replies

  • Hi Rajesh:

    I have alerted protocol documentation team about your inquiry. A member of the team will be in touch soon.


    Regards, Obaid Farooqi
    Saturday, March 26, 2011 9:57 PM
    Owner
  • Hi Rajesh, 

    I've been assigned to assist you with this problem.  I will get back to you shortly with more information.

    Best regards,

    Tom Jebo

    Microsoft Open Specifications

    Wednesday, March 30, 2011 2:05 PM
  • Hi Rajesh,

    Dynamics itself does not know what the value of the field is supposed to be when informing its client (RDB in the example below); it only knows that the current value needs to be undone in order to coalesce the changes from one or more endpoints.  Storage of the previous value of the field is an implementation detail of the client, in this case RDB.  RDB stores the previous value for fields on executing each 'Set Field' command, reapplying them as the current value when instructed by Dynamics to Undo. This Do/Undo behavior works the same way for all the commands documented in  MS-GRVRDB - Add Record, Add Records, Delete Record, and Set Field, with only Set Field needing to store a previous value (the Undo of the other commands just reverses the operation).

    Best regards,
    Tom Jebo
    Escalation Engineer
    Microsoft Open Specifications

    Wednesday, April 6, 2011 4:34 PM
  • Thanks for the explanation. I still have one question.

    If there are two commands that set a same field on same record from A to B and then B to C. Do the underlying implementation need to remember all previous values B, A?

    In this way how many previous versions of the same record are needed for proper implementation of the Dynamics?

    Thanks in advance

    Rajesh

    Wednesday, April 6, 2011 5:07 PM
  • Ok Rajesh,  I'm looking into it.

    Tom

    Thursday, April 7, 2011 7:12 PM
  • Rajesh,

    The Dynamics client needs to keep previous values for all field value transistions until such a time as it knows that all endpoints have coalesced on the same value for the field in the record.  Once the data is at steady state on all endpoints the previous versions of the field value may be purged.  Deciding when to purge (if at all), and whether this is done automatically by Dynamics or in concert with its clients, e.g. RDB, is an implementation detail.

    Tom

    Friday, April 8, 2011 3:12 PM
  • Hi Tom,

    Is there any way in Dynamics that we can get to know that each peers have same value for the record?

    I mean how can we find if data is in steady state or not on all peers?

    Rajesh

    Friday, April 8, 2011 4:25 PM
  • Hey Rajesh,  I'm looking into this.

    Tom

    Friday, April 8, 2011 7:55 PM
  • Hi Rajesh,

    The key to deciding whether a delta has been processed on all endpoints is the Delta Ack message.  See sections 2.2.2, 3.1.5.2.6, and 3.1.5.4 for details.  The implementor will need to store Delta Ack messages and process them - once they have received a Delta Ack from each of the other endpoints for a particular delta they will know that the particular delta has been processed on all endpoints.  See section 4.5 for an example of delta message processing.

    Best regards,
    Tom Jebo
    Escalation Engineer
    Microsoft Open Specifications

    Monday, April 11, 2011 6:16 PM