RFID conference sign-in system summary (8)-Data Synchronization

 

The formal approach to data synchronization is to useSQL-ServerBut copying is a little tricky here.

From the very beginning, considering the size of the client database and other requirements of the clientMSDEInstall oneSQL-ServerIt is a waste of resources. Considering that the technology of binding to the database platform is not a good choice for the future application of the system. More importantly, in the system, the data synchronization pressure is not very high, and the situation is not complex. to dynamically update a table, we need to fix those columns, the concurrency conflict policy is also very simple. It is possible to implement the competent data synchronization function of the system within the foreseeable time. The final implementation is actually simpler than what I first designed (because the customer does not need some features ).

 

there are three tables (not two) related to data synchronization ), in DB server and Local dB each of the above tables records the attendance of all attendees, Local dB there is a local sign-In table, only persons who sign in on the local machine are recorded. Of course, using two tables can also achieve the same function, as long as you add more signs, but it will be a lot of complicated, and it is easier to produce concurrency conflicts.

currently, data synchronization is divided into two processes, I call it the upload Process ( abbreviation U) and the drop-down process ( abbreviation d) .

Upload Process(U): Local sign-in personnel fromLocal DBUploadDB ServerThe significance of this process is to make the Management Terminal check-in monitoring and statistics have a basis, and at the same time as the source of the pull-down process. For details, see

The process involves three steps:

1,SlaveLocal DBObtain the local sign-In records that have not been uploaded

2,If there are records, update them accordingly.DB ServerAttendance Schedule on

3,If the update is successful, set the upload mark of this batch of local sign-In records to "uploaded"

 

Drop-down process (D) : Slave DB Server In the sign-in list, pull the latest sign-In records in the recent period, update Local DB Attendance Schedule ( Local DB The attendance schedule must be consistent DB serve The reason for consistency is to determine whether the current sign-in is the "first" sign-In). For the specific process, see


This process is simpler, with only two steps:

1,Obtain the Check-in records of other check-in terminals in the recent period.

2,If there are records, update them accordingly.Local DBAttendance details on

 

The above two processes are repeated inProgram.

 

Note:

A) In the system, I use time as a marker to identify which Check-in records have been obtained in the previous cycle. InU2 Step, the current upload time will be recorded on each update record (the update isDB Server During the storage process, the clock inconsistency of each sign-in terminal will not be affected ). The recent period is actually the period after the maximum upload time point recorded in the previous drop-down period.

B)Only records of other check-in terminals are obtained. This is to reduce the transfer volume of a bit of data.Local DBAt the same time, it is recorded in the check-in schedule and the local login table.

 

Data Synchronization in the system is not for fun, as we know in the previous module Overview (I,Local DBThe emergence of data synchronization is completely for the needs of offline operation. After the above "three tables and two processes" operation, this requirement is basically met. The next step is to add a database connection monitoring function. IfDB ServerUnable to connect, so the above process can jump out directly in a certain step (or jump out after an exception occurs ).

database connection monitoring, originally expected Database Availability monitoring, but in .. NET 1.1 in idbconnection interface state attributes are the same as chicken ribs, therefore, you can only monitor whether the connection is normal (the physical connection of the machine is normal, and you need to correct it later ).

Finally, to display the client, the Data Synchronization component publishes several events, such as database connection change events and sign-In change events. At the same time, some attributes are opened for external settings, such as the synchronization interval and connection monitoring interval (because the system only has general requirements on real-time performance, therefore, the open settings allow the customer to determine the above values based on the actual situation ).

 

theoretical issues : There is a theoretical question in this synchronization process. Question, that is, the judgment of the first sign-in. This judgment is based on Local dB on the attendance schedule, in theory, this table is not the first sign-in schedule. If the same sign-In person signs in at more than one place within a synchronization cycle, then in each place, the system regards it as the first sign-in. However, under normal circumstances, this is only a theoretical problem, because the data synchronization cycle is generally very short, that is, several seconds, and each sign-in terminal is scattered everywhere, A single sign-in user cannot patronize more than one sign-in terminal within one cycle. If the network is abnormal, or DB server it cannot work normally. Under this topology, any technical means cannot solve the issue of checking the first sign-in. Therefore, this theoretical problem will not become a problem.

 

Further steps : The data synchronization mentioned above is only the synchronization of dynamic data, and static data is also synchronized in the system. Because the data volume of a table is not too large, using Table copy can basically solve the problem. At the beginning of the design, in order to reduce unnecessary operations and traffic DB Server Some data tables with changed table data will be recorded. When the sign-in terminal is started, or the control terminal sends a dispatch command (the sign-in terminal can also send a request command ), the data synchronization component synchronizes the static data of the changed tables. Because the unit test of static synchronization is not as full as dynamic synchronization, some programs were found during the integration test at the client. Bug And if DB Server When the data update volume is large, the start time of the check-in terminal will be increased. The customer wants to restore to the previous mode that only distributes and copies data from all the data tables on the control end. This mode is sometimes locked for a long time. UI . However, this action is only performed in the sign-in preparation phase and in the control end UI One or two minutes of locking is acceptable, which is a method they are familiar. Finally, they changed to the pattern they requested. However, I am not quite satisfied with one piece of data. If you have the opportunity to improve it in the future.