CN103475721A - System for updating digital assets and method thereof - Google Patents

Abstract

The invention relates to the field of computer technology, in particular to a system and method for updating digital assets. Including client, server, time server and database; the client can be multiple, each client has a unique identifier, maintains an index list of its own, records in the list from the last update to the present The data index that has changed so far and the last update time provided by the time server; the server provides a database of digital resources; a system index list is stored in the database; the time server provides an accurate and reliable last update Time; the "last update time" of all clients is uniformly provided by the time server to prevent data anomalies caused by time errors. The invention provides a set of reliable and effective multi-terminal data consistency maintenance system and method; it can be used for multi-terminal data maintenance.

Description

System and method for updating digital assets

technical field

The invention relates to the field of computer technology, in particular to a system and method for updating digital assets. the

Background technique

Among the current update technologies, many are online real-time data updates based on a single client scenario, resulting in more restrictions in terms of space and network. However, the type of terminal is no longer a single PC terminal, and mobile terminals such as mobile phones and tablet computers are constantly being introduced and occupy a huge market share. A user needs to use application software at different terminals, different locations, and at different times, which also leads to the problem that the user's data is difficult to maintain consistency on multiple terminals. Obviously, with the increase of data itself and multiple devices of users, the current update technology can no longer meet the needs of users. Therefore, more and more software now implements new update technologies aimed at the characteristics of multiple devices for users. the

Contents of the invention

One of the technical problems solved by the present invention is to provide an update system for digital assets; to solve the current problem of inconsistency in update data under the circumstances of multiple devices, multiple locations, and different times. the

The second technical problem solved by the present invention is to provide a method for updating digital assets; it can realize the business operation of the business systems on multiple clients out of the online environment, and can independently perform the update operation when the network allows, and completes It has the same business function as online connection, and can maintain the data consistency of each terminal, so that the original fixed business is no longer limited by space. the

The technical scheme that the present invention solves one of above-mentioned technical problem is:

Including client, server, time server and database;

There can be multiple clients, each client has a unique identifier, and maintains an index list of its own, which records the data index changed since the last update and the time server provided by the time server. Last update time;

The server provides a database of digital resources; a systematic index list is stored in the database;

The time server provides an accurate and reliable last update time; the "last update time" of all clients is uniformly provided by the time server to prevent data anomalies caused by time errors. the

The technical scheme that the present invention solves above-mentioned technical problem two is:

Each client has a unique identifier and maintains its own index list, which records the data index changed from the last update to the present and the last update time provided by the time server; the server database Each piece of data in the index list identifies which client the data comes from through an identifier;

When updating, first update the data, and then update the index list; maintain the consistency between the data of each client and the index list; the data update operation includes the upload and download of metadata and resources, and each data update operation is relatively independent and supports concurrent execution;

In the index update operation, the server obtains the index update result by comparing its own index list with the index list submitted by the client; the result includes the operation information and new Last update time;

The client generates request information for each operation of data update according to the response result in the index update operation;

The client merges the legacy operation into the request information, sends the data update request through multi-threading, and finally judges the response result of the server. If it succeeds, it will update the relevant data in the local index list. If it fails, it will add it to the legacy operation and delay it until the next time. The update operation is performed. the

A digital asset represents the unit carrier of the note content that belongs to the user; a digital asset is composed of two parts: metadata and resources; digital assets and resources have a one-to-many relationship, and multiple digital assets can refer to the same resource. the

The index updates described are:

The client submits an "index update" request to the server, which includes a list of digital asset ids used by the server to update the user's deletion operation on the local client, and used to determine whether the resource exists on the server to avoid repeated submissions The resource id list, source, user unique identifier and the last update time of the local index list;

The server deletes the corresponding digital assets according to the digital asset id list submitted by the client, and then updates the source and status of the relevant digital assets in the index list;

The server looks up the "last update time" of the client in the index list so far, and adds it to the response result;

The server checks whether the same resource exists in the database according to the resource id list, and adds the result of the check to the response result;

The server adds the new last update time to the response result and sends it back to the client in the form of XML data;

The client parses the response result of the server, merges the corresponding data update operations and historical legacy operations, generates data update request information; and updates the "last update time" sent by the server to the index list. If no response message is received, it is considered that the index update has failed, and the entire update operation ends. the

The metadata download described is:

If there is a digital asset whose status is newly added or modified in the index update result, submit a "metadata download" request to the server. The request includes a list of digital assets with a digital asset id and status, and a user unique identifier. Otherwise, no A request needs to be submitted;

The server receives the "metadata download" request, and adds the digital asset metadata (excluding resources) whose status is new and the modified part of digital assets whose status is modified to the response result;

The server sends the response result back to the client in the form of XML data;

The client obtains the metadata and modified part of the digital asset according to the response result, updates the local index list after updating the local data; if no response is obtained or the response is abnormal, it is considered that the "metadata download" operation failed, and the operation is added to Historical legacy operation. the

The metadata upload described is:

Send a "metadata upload" request to the server using the newly added digital assets locally during the period from the last update time to the last update time as request information;

The server receives the "metadata upload" request and writes digital assets into the database;

Update the index list of the server;

Send an empty response result to the server;

If the client receives an empty response result, it means that the "metadata upload" operation is successful; otherwise, the operation is regarded as a failure, and the operation is added to the legacy operations. the

The resource upload and download described are:

The client sends a "resource upload and download" request to the server with the list of resources to be uploaded to the server or the list of resource ids to be downloaded as request information;

The server judges whether it is resource upload or resource download according to the request information. If it is a resource upload, it will write the resource into the database and return an empty response result; if it is a resource download, it will search for related resources according to the resource id list, and will find The result is returned after adding the response result;

Judging the response result of the server, if it is a normal response, the "resource upload and download" operation is successful, otherwise it is considered that the "resource upload and download" operation has failed, and this operation is added to the historical legacy operations. the

The "last update time" of all terminals in the present invention is uniformly provided by the time server to prevent data anomalies caused by time errors. Each terminal maintains its own index list, which records the data indexes that have changed since the last update; the data is updated by comparing the index lists to finally achieve the maintenance of data consistency. Each data update operation is relatively independent and supports efficient execution through concurrency. Any failure in the data update operation on the terminal will be incorporated into the next update index list; thus ensuring the final consistency of the data. Through the use of the present invention, the atomicity in time of each update operation can be guaranteed, and the data anomaly problem caused by the time difference between multiple terminals can be prevented; through data update, the user can perform the same operation as the online connection in an off-line environment. business operations; users can obtain updated business operations in other terminals on any terminal. The invention provides a set of reliable and effective multi-terminal data consistency maintenance system and method. the

Description of drawings

The present invention is further described below in conjunction with accompanying drawing:

Fig. 1 is a system block diagram of the present invention;

Fig. 2 is a flowchart of the inventive method client;

Fig. 3 is a sequence diagram of the specific implementation of the method of the present invention. the

Detailed ways

As shown in Figure 1-3, the present invention:

1. Each client has a unique identifier (origin) and maintains its own index list, which records the data index that has changed since the last update and the last update time provided by the server. And each piece of data in the index list of the server uses origin to identify which client the data comes from;

2. Update the data first, and then update the index list. Keep each client data consistent with the index list. the

3. In the index update operation, the server obtains the index update result by comparing its own index list with the index list submitted by the client. The result includes the operation information of the client from other sources of the user from the last update time to the present and the new last update time. the

4. The client generates request information for each operation of data update according to the response result in the index update operation. the

5. The client merges the historical legacy operation into the request information and sends a data update request through multiple threads, and finally judges the response result of the server. If it succeeds, it will update the relevant data in the local index list. If it fails, it will add it to the historical legacy operation and delay until The next update operation is performed. the

The digital asset of the present invention: represents the unit carrier of the note content owned by the user. A digital asset consists of metadata and resources. In addition, digital assets and resources have a one-to-many relationship, which means that multiple digital assets can refer to the same resource. the

Specific implementation steps:

1. Index update

1.1 The client submits an "index update" request to the server, and the request includes a list of digital asset ids (used by the server to update the deletion operations performed by the user on the local client), a list of resource ids (used to determine whether the resource is in the service End existence, to avoid duplicate submissions), source (origin), user unique identifier (owner) and the last update time of the local index list. the

1.2 The server deletes the corresponding digital assets according to the digital asset id list submitted by the client, and then updates the source and status of the relevant digital assets in the index list. the

1.3 The server looks up the "last update time" of the client in the index list so far, and adds the user's operation information on the client from other sources to the response result. the

1.4 The server checks whether the same resource exists in the database according to the resource id list, and adds the result of the check to the response result. the

1.5 The server adds the new last update time to the response result and sends it back to the client in the form of XML data. the

1.6 The client parses the response result of the server, merges the corresponding data update operations and historical legacy operations, and generates data update request information. And update the "last update time" sent by the server to the index list. If no response message is received, it is considered that the index update has failed, and the entire update operation ends. the

2. Metadata download

2.1 If there is a digital asset with status C (new) or U (modified) in the index update result, submit a "metadata download" request to the server, and the request includes a list of digital assets (digital asset id, status) and the user unique identifier (owner). Otherwise there is no need to submit a request. the

2.2 The server receives the "metadata download" request, and adds the digital asset metadata (excluding resources) with status C (new) and the modification part of digital assets with status U (modified) to the response result. the

2.3 The server sends the response result back to the client in the form of XML data. the

2.4 The client obtains the metadata and modified part of the digital asset according to the response result, updates the local index list after updating the local data. If no response is obtained or the response is abnormal, it is considered that the "metadata download" operation has failed, and this operation is added to the historical legacy operations. the

3. Metadata upload

3.1 Use the newly added digital assets locally during the period from the last update time to the last update time as the request information, and send a "metadata upload" request to the server. the

3.2 The server receives the "metadata upload" request and writes the digital assets into the database. the

3.3 Update the index list of the server. the

3.4 Send an empty response result to the server. the

3.5 If the client receives an empty response result, it means that the "metadata upload" operation is successful; otherwise, the operation is deemed to have failed, and the operation will be added to the legacy operations. the

4. Resource upload and download

4.1 The client sends a "resource upload and download" request to the server with the list of resources to be uploaded to the server or the list of resource ids to be downloaded as request information. the

4.2 The server judges whether it is resource upload or resource download according to the request information. If it is a resource upload, it will write the resource into the database and return an empty response result; if it is a resource download, it will search for related resources according to the resource id list. The search result is added to the response result and returned. the

4.3 Judging the response result of the server, if it is a normal response, the "resource upload and download" operation is successful, otherwise it is considered that the "resource upload and download" operation has failed, and this operation will be added to the historical legacy operations

also,

1. The request information of "Index Update" and "Metadata Upload" needs to include the origin to identify which client the digital asset comes from, because these two requests require the server to update the index list. the

2. Considering that there is a many-to-one relationship between digital assets and resources and the size of resources will affect the response time, the upload and download of resources are separated into the "resource upload and download" request. the

3. "Metadata download", "metadata upload" and "resource upload and download" operations need to merge historical legacy operations before sending the request before sending the request. the

4. "Metadata download", "metadata upload" and "resource upload and download" do not have sequence constraints, and can be executed concurrently, thereby increasing update efficiency. the

Claims (9)

1. A digital asset update system, characterized in that: comprising a client, a server, a time server and a database; There can be multiple clients, each client has a unique identifier, and maintains an index list of its own, which records the data index changed since the last update and the time server provided by the time server. Last update time; The server provides a database of digital resources; a system index list is stored in the database; The time server provides an accurate and reliable last update time; the "last update time" of all clients is uniformly provided by the time server to prevent data anomalies caused by time errors. 2. A method for updating digital assets of the system according to claim 1, characterized in that: Each client has a unique identifier and maintains its own index list, which records the data index that has changed since the last update and the last update time provided by the time server; the server database Each piece of data in the index list identifies which client the data comes from through an identifier; When updating, first update the data, and then update the index list; maintain the consistency between the data of each client and the index list; the data update operation includes the upload and download of metadata and resources, and each data update operation is relatively independent and supports concurrent execution; In the index update operation, the server obtains the index update result by comparing its own index list with the index list submitted by the client; the result includes the operation information and new Last update time; The client generates request information for each operation of data update according to the response result in the index update operation; The client merges the legacy operation into the request information, sends the data update request through multi-threading, and finally judges the response result of the server. If it succeeds, it will update the relevant data in the local index list. If it fails, it will add it to the legacy operation and delay it until the next time. The update operation is performed. 3. The digital asset update method according to claim 2, characterized in that: the digital asset represents the unit carrier of the note content owned by the user; a digital asset is composed of metadata and resources; digital assets and resources are one To-many relationship, multiple digital assets can refer to the same resource. 4. The digital asset update method according to claim 2 or 3, characterized in that: said index update is: The client submits an "index update" request to the server, which includes a list of digital asset ids used by the server to update the user's deletion operation on the local client, and used to determine whether the resource exists on the server to avoid repeated submissions The list of resource ids, sources, user unique identifiers and the last update time of the local index list; The server deletes the corresponding digital assets according to the digital asset id list submitted by the client, and then updates the source and status of the relevant digital assets in the index list; The server looks up the "last update time" of the client in the index list so far, and adds it to the response result; The server checks whether the same resource exists in the database according to the resource id list, and adds the result of the check to the response result; The server adds the new last update time to the response result and sends it back to the client in the form of XML data; The client parses the response result of the server, merges the corresponding data update operations and historical legacy operations, generates data update request information; and updates the "last update time" sent by the server to the index list. If no response message is received, it is considered that the index update has failed, and the entire update operation ends. 5. The digital asset update method according to claim 4, characterized in that: the downloading of the metadata is: If there is a digital asset whose status is newly added or modified in the index update result, submit a "metadata download" request to the server. The request includes a list of digital assets with a digital asset id and status, and a user unique identifier. Otherwise, no A request needs to be submitted; The server receives the "metadata download" request, and adds the digital asset metadata (excluding resources) whose status is new and the modified part of digital assets whose status is modified to the response result; The server sends the response result back to the client in the form of XML data; The client obtains the metadata and modified part of the digital asset according to the response result, updates the local index list after updating the local data; if no response is obtained or the response is abnormal, it is considered that the "metadata download" operation failed, and the operation is added to Historical legacy operation. 6. The digital asset update method according to claim 4, characterized in that: the uploading of the metadata is: Send a "metadata upload" request to the server using the newly added digital assets locally during the period from the last update time to the last update time as the request information; The server receives the "metadata upload" request and writes digital assets into the database; Update the index list on the server side; Send an empty response result to the server; If the client receives an empty response result, it means that the "metadata upload" operation is successful; otherwise, the operation is regarded as a failure, and the operation is added to the legacy operations. 7. The digital asset update method according to claim 4, characterized in that: the resource upload and download are: The client takes the list of resources to be uploaded to the server or the list of resource ids to be downloaded as request information, and sends a "resource upload and download" request to the server; The server judges whether it is resource upload or resource download according to the request information. If it is a resource upload, it will write the resource into the database and return an empty response result; if it is a resource download, it will search for related resources according to the resource id list, and will find The result is returned after adding the response result; Judging the response result of the server, if it is a normal response, the "resource upload and download" operation is successful, otherwise it is considered that the "resource upload and download" operation has failed, and this operation is added to the historical legacy operations. 8. The digital asset update method according to claim 5, characterized in that: the uploading of the metadata is: Send a "metadata upload" request to the server using the newly added digital assets locally during the period from the last update time to the last update time as the request information; The server receives the "metadata upload" request and writes digital assets into the database; Update the index list on the server side; Send an empty response result to the server; If the client receives an empty response result, it means that the "metadata upload" operation is successful; otherwise, the operation is regarded as a failure, and the operation is added to the legacy operations. 9. The digital asset update method according to claim 8, characterized in that: the resource upload and download are: The client takes the list of resources to be uploaded to the server or the list of resource ids to be downloaded as request information, and sends a "resource upload and download" request to the server; The server judges whether it is resource upload or resource download according to the request information. If it is a resource upload, it will write the resource into the database and return an empty response result; if it is a resource download, it will search for related resources according to the resource id list, and will find The result is returned after adding the response result; Judging the response result of the server, if it is a normal response, the "resource upload and download" operation is successful, otherwise it is considered that the "resource upload and download" operation has failed, and this operation is added to the historical legacy operations.

Images