Share via

3.1.1.2.2 Algorithm for Processing Synchronization Results for Concurrency

  • Article

A TableGram, as specified in section 2.2.3.14, can contain new result data or commands for changing the database. When the TableGram contains commands for changing a database, these commands are known as a DiffGram. This section describes how a DiffGram is processed. A DiffGram represents changes from the client-side RecordSet that can be applied to the server-side RecordSet, so that the client-side and server-side RecordSets are synchronized.

Clients that are using RecordSets to manage data are making changes to a locally cached copy of the server's data. The client RecordSet is initially populated from a snapshot of the data from the server. Based on input from the higher-level application, the client RecordSet can be changed and sent to the server. While the client retained the snapshot of the data from the server, there might have been other applications changing that same data on the server. The system is responsible for managing the concurrent access to the records on the system.

A DiffGram MUST contain the following:

  • A sequence of insert, update, and delete commands that specify the required changes to the data store.

  • New values that are to be stored in the data store.

  • Concurrency information. Data that contains the initial version of the data from the server.

Concurrency information provides the information necessary to determine if any changes to the current record of data are applied to a record of data that was changed on the server from a different client. If the data on the server has been changed by another processing system, then the current change is considered stale and MUST NOT be applied.

Concurrency information can come in four forms:

  • Time stamp: The record carries a date and time that denotes the last update date and time for this version of the data record. If the record in the data store has a new time stamp than the one in the update, then the update data is stale and MUST be rejected.

  • Original version of the data: The update record contains an original copy of all of the values of the record. That copy reflects the original version of the data when the RecordSet was populated. If the record in the data store has changed in any of the values from the update record, the update request is stale and MUST be rejected.

  • Original version of the data, updates only: The update record contains a copy of the original version of the data for any fields that are in the update command. The copy reflects the original version of the data when the client RecordSet was populated. If the record in the data store has changed in any of the values from the update record, the update request is stale and MUST be rejected.

  • Original version of the data, keys only: The update record contains a copy of the original versions of the data for any key fields. The copy reflects the original version of the data when the client RecordSet was populated. If the record in the data store has changed in any of the values from the update record, the update request is stale and MUST be rejected.

If the update is not applied for concurrency reasons, the server MUST append (see Error Handling, section 3.3.5.1.2) the entry to the rdsStatusArray (see section 2.2.3.13.10).