JP5543918B2 - Conflict resolution method for parallel database editing - Google Patents

Description

The present invention solves editing conflicts that occur when a database (hereinafter “DB”) is edited in parallel (hereinafter “parallel DB editing”) for a plurality of replicas.

In general, a database is placed in a server computer (hereinafter “server”), and an operation is performed in which a plurality of terminal computers (hereinafter “PC”) access. In order to prevent access conflicts, a vestigec lock cursor (Non-Patent Document 1) and a transaction lock (Non-Patent Document 2) are used.

MVCC (Non-Patent Document 3) also uses an edit lock (Non-Patent Document 4 and Non-Patent Document 5), and OODB products Cache (Non-Patent Document 6) and ObjectStore (Non-Patent Document 7) also use an edit lock. In PostgreSQL of relational DB (RDB), “Use appropriate LOCK TABLE statement to avoid updates that can occur at the same time” (Non-Patent Document 5) is also an edit lock. Patent Document 1 is also an edit lock.

Attempts have been made to improve the efficiency of processing and communication by using a cache technology that performs processing by creating a working copy. Microsoft's ADO.NET copies the data necessary for the immediate work to the PC from the server, cuts the connection with the server, and then edits. After editing, connect to the server again and send the edited content to the server. If the information to be edited has already been changed from another PC, the later (this) editing is invalidated. This is called “optimistic concurrency control” (Non-Patent Document 8 and Non-Patent Document 9). It can be said that it is a kind of editing lock if it is considered that “the editing is invalidated when the lock fails as a result”. In the present application, this method is referred to as “first-come-first-served” for comparison with other methods. This “first-come-first-served” sometimes causes the following inconveniences.

(1) There are cases where editing based on the latest information is invalid. Editing based on the latest information is likely to be the best decision at the time, and if this becomes invalid, it becomes a problem in actual operation.

For example, it is assumed that the operator of the PC-X copies necessary data from the server at 9:00 am, writes “This customer is chilly, so no friendly response is required”, and then left for a while. On the other hand, the operator of PC-Y got the information “There is a proposal for an expensive transaction from this customer” at 12:00 noon, wrote “I will do the maximum entertainment for the contract” and uploaded it to the server. And However, if editing from the PC-X is uploaded one minute before that, the editing of the PC-Y is invalidated since it is later. Editing of the PC-Y based on the latest information is obstructed by a whimsical operation of the PC-X operator.

(2) Since a copy is created for each edit (p19 of Non-Patent Document 1), the copy creation processing and communication become overhead. To reduce this overhead, it is necessary to limit the scope of copying, but this requires knowledge of the structure of the information targeted by the application. This is a common problem with cache-based methods.

Even in Patent Document 2, if a record in a specified range is updated, later update is invalidated. Specifically, at the bottom of page (6) of the cited invention, “If it is found that the record has been updated by another process, the update is rejected”. This is “first-come-first-served” and has the same problem as ADO.NET.

In Patent Document 3, based on the editing time in the duplicate DB, the competing editing versions are “re-referenced from the earliest time (Step S604)” (paragraph 0065 and paragraph 0079 in Patent Document 3), and “Update content information with the oldest date and time to the latest version” (paragraph 0097). In other words, the one that was edited first is given priority. In the present application, this method is referred to as “first edit priority” for comparison with other methods.

There may be a problem even with “first edit priority”. For example, if there is an editing result at a certain time (for example, one year ago) in a PC, and it is suddenly uploaded to the server one day and activated, it has been edited and uploaded by the other PC in the past year. All edits will be invalid. Such operations are not normally allowed. Note that Patent Document 4 also has the same problem because the update time is valid for the previous update.

In Patent Document 5, an update with a later update time is valid. In the present application, this method is referred to as “unconditional overwrite” for comparison with other methods. In this document, it is assumed that the correction on the PC is transmitted to another PC almost in real time. Therefore, the later editing is presumed to be correction after grasping all the editing statuses up to that point. Under this condition, there seems to be no problem with "Unconditional Overwrite".

However, in the case where a plurality of PCs change the contents of the duplicate DB held by each of the PCs as in the present application, the editing status on the other PCs is not immediately transmitted. In this situation, if “unconditional overwrite”, which is always overwritten if the update time is later, is applied, the effectiveness of editing is determined for reasons that cannot be directly understood by the PC operator. It is necessary to consider the possibility that the clock of each PC that determines the editing time may be shifted or that the clock may be shifted intentionally. There are many issues that need to be considered when applying "Unconditional Overwrite" to parallel editing.

Other survey results are shown below. Patent Document 6 is an invention relating to a condition for starting the synchronization of a database, and the synchronization method merely shows a general synchronization concept of “synchronizing by notifying each other of update information”. By simply notifying each other of updates created in parallel (“edit record” in the present application), the order of application to the DB differs for each PC for various reasons (delay due to error retransmission, transmission timing deviation, etc.). There is a possibility that a serious problem is expected that the contents of each replicated DB are different. However, no countermeasure has been shown for this.

Patent Document 7 is an invention for the purpose of “holding all update data” when an editing conflict occurs. The original is updated only when there is no conflict, and the object and contents are different from the present invention.

Non-Patent Document 10 is an invention related to file caching, and when it detects an edit conflict (competition in this application), it simply rejects the edit (10th line from the lower right on page 7 of Non-Patent Document 10). Therefore, it is not determined which of the edited editing is effective as in the present application.

Although Patent Literature 8, Patent Literature 9, Patent Literature 10, Patent Literature 11, and Patent Literature 12 were also investigated, none of them can be applied to the contradiction resolution by parallel DB editing, which is the purpose of the present application.
Japanese Patent Laid-Open No. 11-272534 JP-A-61-134853 JP 2005-216167 A JP 9-91184 A Japanese Laid-Open Patent Publication No. 2004-13867 JP 2004-86800 A JP 2006-284998 A JP 11-161535 A JP 2005-503606 Gazette Special table 2005-508050 gazette JP-A-8-16447 JP 2000-501532 A William R. Vaughn, translation of top studio, supervised by Yukiko Ito, Windows (registered trademark) database programming ADO.NET special course VB.NET edition, August 4, 2003, first edition issued, Shosuisha Super Illustrated SQL Handbook, C & R Laboratories, first published on August 12, 2005 “Main functions and benefits”, [online], search on April 22, 2007, Internet (URL: http://www.sonicsoftware.co.jp/products/object_store/function.html) "MVCC (Multi-version concurrent execution control) 9.1. Introduction", [online], search on April 22, 2007, Internet (URL: http://www.postgresql.jp/document/pg721doc/user/mvcc.html #MVC C-INTRO) “9.5. Checking Data Consistency at the Application Level”, [online], April 22, 2007 search, Internet (http://www.postgresql.jp/document/pg721doc/user/applevel-consistency.html) "Cache Technology Guide", [online], search April 22, 2007, Internet (URL: http://www.intersystems.co.jp/cache/technologyguide/technologyguide.html) “Main functions and benefits”, [online], search on April 22, 2007, Internet (URL: http://www.sonicsoftware.co.jp/products/object_store/function.html) "Outline of data concurrency control in ADO.NET", January 2007, MSDN subscription library (msdn subscriptions Library), disk file (URL: ms-help: //MS.MSDNQTR.v80.en/MS. MSDN.v80 / MS.VisualStudio.v80.en / dv_raddata / html / d5293098-4a88-4110-abd2-34d9e6661664.htm) “Tutorial: Handling Concurrency Exceptions”, January 2007, MSDN Subscriptions Library, disk file (URL: ms-help: //MS.MSDNQTR.v80.en/MS.MSDN.v80 /MS.VisualStudio.v80.en/dv_raddata/html/73ee9759-0a90-48a9-bf7b-9d6fc17bff93.htm) "World-wide distributed file system SKINNY", Information Processing Society of Japan Research Report, 95-OS-70, (Academic Publications Institute of Information Processing Vol. 95, No. 79 ISSN 0919-6072

An object of the present application is to solve an “editing conflict” that occurs when DB replication exists in a plurality of PCs and parallel DB editing is performed on these PCs in parallel. Although the "first-come-first-priority", "first-edit priority", and "unconditional overwrite method", which are extensions of the cache technology, were examined, these had various problems. The replica DB held by each PC is positioned as a temporary replica as a cache, and it is estimated that some problems are ignored. The present application proposes a full-fledged “parallel DB editing” in which each PC permanently holds a duplicate DB, and clarifies a method of editing conflict resolution suitable for this. Also consider application to cache technology.

In the present invention, editing conflicts in parallel DB editing are resolved with a policy of “prioritizing editing based on the latest information”. The case used for full-fledged parallel database editing and its application to cache technology will be described. Below, it demonstrates based on one example of application.

(1) Preparation A replica DB (hereinafter “local original DB”) in an initial state of an original DB (hereinafter “global original DB”) is placed on a plurality of PCs. In this local original DB, an initial version, that is, an order number for identifying the update order, is set.

A simple implementation of this order number is an integer, and it is natural to set “0” as the initial value. In this application, this version is used to resolve conflicts. Each PC updates the version of the duplicate DB at their respective (possibly operator's) convenience. Details of this will be described below.

(2) Local editing Each PC performs local editing on the local original DB held by the PC. Before this editing, a working copy of the local original DB is created, and editing is performed on this copy. In addition, the “edit record” is created at the time of editing. In this edit record, “edit contents”, “edit version”, “invariant confirmation range”, and the like are recorded.

“Edited contents” are general edited contents such as which information has been changed in what manner, which information has been added, and which information has been deleted. “Edited version” is the version of the local original DB to be edited, strictly speaking, the version of the local original DB that is the replication source of the work DB to be edited.

The “invariant confirmation range” is a range of information assumed by this editing. If this range of information is changed before the edit is finalized, this indicates that the edit is meaningless. The “invariant confirmation range” can be specified in various ways according to the characteristics of information handled by the DB, particularly the information to be edited. In general operation, the information to be edited seems to be in the “invariant confirmation range”, but it is not always necessary to enter it. In the case of a relational DB (hereinafter “RDB”), a table to be edited, a group of tables logically related to the object to be edited, a part of the records, or the entire DB can be considered.

By setting an appropriate invariant confirmation range according to the nature of the information, the usability of the DB is improved. If the “invariant confirmation range” is small, many parallel editing can be performed without any problem. Therefore, it is preferable to set the indispensable minimum information (combination) as the invariable range.

(3) Transmission of edit record to server Each PC transmits “edit record” to the server. If "Edit Record", "Edit Version", and "Invariant Confirmation Range" are recorded separately, "Edit Version" and "Invariant Confirm Range" are also sent clearly indicating the correspondence with "Edit Record" . If the “edit version” and “invariant confirmation range” and “version setting range” described later are recorded in the “edit record”, the communication procedure is simplified.

(4) Receiving edit records by the server The server records the edit records that have arrived from the PC together with the order of arrival.

(5) Receiving edit records from the server The PC requests the server to send unedited edit records, and receives these edit records, the corresponding edit versions, and if necessary the invariant confirmation range and version setting range. To do. At the same time, the order of arrival of edit records to the server is received. If the server records the arrival order in the edit record that arrives from the PC, the communication procedure is simplified.

(6) The local original DB update PC retrieves the edit records received from the server in the specified order, and determines the validity of the edit records. Details of this determination procedure will be described later in “Effectiveness Determination Procedure”. Then, the local original DB is updated to update its version. If the version is an integer, it is natural to increase the value one by one from the initial value “0”. Note that the PC processes all the specified editing records to the end (no new editing work is entered on the way). Therefore, the local original DB may be updated at a stroke until the last editing record received from the server, and the version may be updated thereafter (by the number of processed editing records).

<Synchronization in time called version>
All PCs take out edit records of local edits in each PC in the order of arrival at the server, update the local original DB, and update its version. Since the same information is used in the same order and processed by the same logic, the local original DB of each PC obtained and the version are synchronized. It is this mechanism that the local original DB of each PC is synchronized even if the global original DB is not updated or the global original DB does not exist.

Each PC updates its local original DB when it is convenient, so when viewed in real time, the progress of the version of the local original DB of each PC varies. However, the order in which the versions are updated is the same. If the versions are the same, the contents of the local original DB are the same. That is, the version corresponds to a time common to each PC in parallel DB access. In other words, in the present invention, the local original DB of each PC is synchronized in the time called version.

The description of setting one version for the entire DB is above. However, when setting a group of information as “version setting range”, which will be described later, the information in the range is updated (added or changed). , Delete), update the version of the range and record the version for each range.

<Effectiveness judgment procedure>
“Determining the validity of an edit record” is an important part of the present invention. When attempting to update the “local original DB” with the edit record (Y), first, the past edit record in which the information of the “invariant confirmation range” specified in Y has been updated is investigated, and all of these are checked. When Y is determined to be valid, Y is determined to be valid. Here, for the sake of explanation, one of the past editing records in which the information of the “invariant confirmation range” designated by Y is updated is X, and the following symbols are used.
y: Y edit version = the version of the “local original DB” that was the edit target of Y.
x: Edit version of X = version of “local original DB” that was the edit object of X.
nx: version of the original set by updating based on X. Naturally, “x <nx”.

The condition that Y is invalid with respect to X is when one of the following two conditions is satisfied. If at least one X is invalid, Y is determined to be invalid, and the local original DB is not updated by Y.

(Condition 1 in which Y becomes invalid) Information of “invariant confirmation range” in which X is Y is updated, and “y <x”. That is, since the edited version of Y is older than X, Y is determined to be invalid.

(Condition 2 for invalidating Y) Information of “invariant confirmation range” in which X is Y is updated, and “y = x”. In other words, if the edited versions match, it is determined that the first X is valid and Y is invalid.

In the conventional “first-come-first-priority” or “first-edit priority” method, there is a problem that editing based on old information is prioritized over editing based on the latest information. Is eliminated.

Conversely, the condition that Y is valid for X is when one of the following two conditions is satisfied. Note that Y is valid when valid for all X, and updating of the local original DB by Y is executed.

(Condition 1 for Y to be valid) When X is not updated with the information of “invariant confirmation range” where Y is Y, Y is valid for X only under this condition.

(Condition 2 for Y to be valid) When “invariant confirmation range” information in which X is Y is updated and “x <y”, Y is valid for X.

When valid for all X, Y becomes valid, and the local original DB is updated by Y. When the principle that the edit version prioritizes the new edit is strictly applied, the update procedure is divided depending on the relationship between y and nx.

In the case of “(x <) nx <= y”: the local original DB to be edited of Y includes X changes. Therefore, the update by Y is executed while the update by X is utilized.

In the case of “(x <) y <nx”: Y is performed on the local original DB that does not include the change of X. Therefore, if the idea of "prioritizing editing based on the latest information" is strictly applied, the update by Y is executed after the update by X is canceled. The condition “(x <) y <nx” is referred to as an “edit cancellation condition” for X.

Actually, when Y is valid in the above (Condition 2 where Y is valid), the condition of “(x <) y <nx” is not confirmed, and the update by X is immediately utilized. A method of executing overwrite update by Y is practical. Naturally, there is a possibility that the principle of “edit version prioritizes new edit” may be lost, but it is convenient for operation that the update applied once is not canceled. The procedure for determining validity is simple and clear, and it is easy for the parties involved in parallel DB access to understand the operation of the database, and the development of the system becomes easy. The details of “operation with cancellation of update” will be described later.

<General operation flow>
A series of operation examples focusing on a certain PC will be described below. It is assumed that this PC receives the latest editing record from the server and updates the local original DB. After that, after the editing record is uploaded from another PC to the server, this PC performs editing on the local original DB. This is uploaded to the server as an edit record Y, then the previous (unreceived) edit record is received from the server, the edit records are taken out in the designated order, and an attempt is made to update the local original DB. In this process, some editing (for example, editing X) is determined to be valid, and the local original DB is updated.

Finally, the edit record Y that has been uploaded earlier is taken out, the invariant confirmation range is investigated, and the relationship with the edit X or the like is evaluated by the “validity determination procedure”. If it is invalid through one X, Y is judged invalid. The operator of this PC confirms the fact of the invalidation and the reason thereof, and tries to edit again (for the latest information) if necessary. If there is a record of the original input that has been invalidated, it is easy to enter the contents again. If it is valid, the local original DB is updated with the edit record Y.

<Almost online operation and almost offline operation>
The operator of the PC only needs to understand that “the editing based on the old information is likely to be determined to be invalid”. In order to minimize the possibility that the editing PC determines that the editing is invalid, the latest editing record is received immediately before editing, the local original DB is updated, and the latest local original DB is updated. It is recommended that the editing be performed and that the editing record be uploaded immediately after editing. If updated frequently, the local original DB is always kept up-to-date, so it can be said that “almost online operation”.

However, when handling information with rare editing conflicts, it is unlikely that editing will be invalidated even if the time from updating the local original DB to editing is increased. For example, in the case where a payment slip is input for each organization of a company, the record is corrected when an input error or a processing error is found, and even if it is corrected, it is often performed by a computer that inputs the record. In such a case, there is no problem even with “almost offline operation” in which the period from update to edit-up is extremely long. Even if you can't connect to the Internet, you can enter payment slips slowly and upload them together when it is close to the settlement or inspection.

<< Overall of the means to solve the problem >>
The full scope of the invention is described below, including variations of the embodiments.

(1) Edit record and its order The edit record and its order transmitted from the operation server to the PC do not necessarily have to be the contents that the PC is up, and it is not necessary to keep the up order. If the edit record and the order are the same for all PCs, these local original DBs are synchronized.

The server or the PC in charge of management work may analyze the contents of the edit record, and delete a portion that becomes invalid due to an error or a redundant portion (same as nothing to do after all). There is no problem even if the editing records of errors or redundant editing records are deleted and the order of editing records is reduced. Even if the order of editing and recording is intentionally changed in consideration of the priority of the operator, the local original DB is synchronized.

(2) In the example of the update destination of the global original DB by the server, the “local original DB” is updated using a series of edits received from the server. By updating the “local original DB” with the same initial value of the “local original DB”, the same order and contents of the edit records applied to it, and the same logic, the “local original DB” of the PC that has received up to the same edit record The contents of the “original DB” match. Although there is no “global original DB”, the “local original DB” of each PC is synchronized. It can be said that it is synchronized with the virtual global original DB.

It is also possible to operate the global original DB actually placed on the server and the server updating the global original DB. The main points are as follows.
(A) A global original DB exists in the server, and each PC has a local original DB that is a copy of the PC.
(B) When editing each local original DB, each PC creates an edit record and sends it to the server.
(C) The server confirms the editing conflict in the order of arrival of the editing records from the PC, updates the global original DB with the editing determined to be valid, and updates the version.
(D) With the information from the server, each PC updates, that is, synchronizes with, its local original DB.

If the original DB is placed on the server, the explanation of the process is simple, but the actual process becomes conversely complicated. One is that it is difficult to notify the PC of the processing process, that is, it is determined which editing is determined to be invalid and how it is determined to be invalid to the operator of the PC that performed the editing. It is difficult. If each PC updates the previous “local original DB”, it is possible to grasp the validity / invalidity of all edits within each PC, but if the server updates the original DB, the situation is detailed. Complicated processing is required to communicate to each PC.

If the server updates the global original DB, there is an advantage that "updating the update process can be performed by updating the server processing program", but considering the balance with the complexity of the above process, the characteristics of the data handled and the convenience of the user Therefore, we will select an appropriate operation.

(2.1) Notification to PC When updating the global original DB, it is necessary to synchronize the latest global original DB and each local original DB. It is common sense to think that there is a large amount of data in the global original DB, and sending the whole is unrealistic. Sending edit records (and their order) to each PC is the same as updating the local original DB on each PC, and the advantage of the server updating the global original DB is small. After all, it is realistic to send the difference information of the global original DB update.

(2.2) Application to the cache For the method of “Creating a copy of the necessary part of the global original DB from the server and editing this copy before editing on each PC” using the cache technology However, the method of “prioritizing editing based on the latest information” of the present application can be applied. When creating a copy necessary for editing, the version of the global original DB is also acquired. In the editing record, this version is set as the editing version and sent to the server. The server determines the validity based on the edited version. As a result, ADO. The case where the editing for the latest version is disturbed by the sudden increase in editing for the old version, as seen in NET, is eliminated.

(3) In the method of updating the “local original DB” described in the server function location, edit records are collected on the server. We also explained how the server updates the global original DB. Both servers can be dedicated servers or rental servers if they can provide the necessary functions. There is no problem even if one of the PCs in this specification provides the functions of the server in this specification at the same time.

(4) It is not necessary that the unit for assigning the introduction version of the version setting range and managing editing is an actual DB. If the influence of the information modification is closely related to the “version setting range” and a version is set for each, the editing and version transition of the range can be managed.

The setting of the optimal version setting range depends on the structure and contents of information to be handled. In the case of RDB, a record, a table, a table group logically related to the table, a specific record group among them, a whole DB, or the like is assumed.

The procedure described above can be applied by replacing DB with a version setting range. There is no problem even if editing for a plurality of version setting ranges is described in one editing record. For each version setting range, “edited contents”, “edited version”, “invariable confirmation range”, etc. may be described.

The medical personal information will be described as an example. The personal medical record is set as the version setting range in the medical information DB. If one or more rows in the table are personal information, a version is set for this chunk. The DB has a lot of personal information, and a version is set for each. In the edit record, there are one or more sets of “edit contents”, “edit version”, and “invariant confirmation range” for each individual. The “invariant confirmation range” may be set appropriately according to the content and purpose of the correction, whether it is the entire personal record or the corrected information (record for RDB). If a table is configured for each personal information, a version is set for each table.

In addition to medical information, it can also be used to manage information such as social guarantees, bank accounts and loans for each individual. It can also be used to manage criminal information that seems to be edited by multiple departments. Furthermore, it is also convenient when handling personal information such as “Management of the Basic Resident Register in a developed form” where some data can be edited by the residents. As explained in “(5) Local original DB replication range”, only the information within the scope of authority is stored in this PC. If sent, there is no risk of unauthorized information being hacked.

(4.1) Version assignment timing A version is assigned to the entire DB original (global original DB or local original DB), or the “version setting range” in the DB original. And can be selected according to operational circumstances.

In the method of “updating a version by valid editing”, the version is updated when the original DB or the version setting range is changed in the change record determined to be valid. The version is the same until it is updated with the next valid editing record, and the version of the local original DB synchronized during this period is the same.

Even if the contents of the original DB are not changed by a valid change record, updating the version is a method of “updating the version by all edit records regardless of validity or invalidity”. The version is different between before and after invalid editing, and the version of the local original DB synchronized later is advanced even if the contents of the original DB are the same.

(4.2) Development to server reception time of editing It is also possible to use the time when the server received the editing record as a version. The version described above will be read as this reception time. The version is described as an order number for identifying a series of orders, but there is no problem because the time also represents the order.

(4.3) Development to the time of synchronous access to the server There is also a method in which the PC accesses the server, acquires the time when the presence or absence of the unrecorded editing record is confirmed, and sets the time as the version of the original DB. Is possible. When updating the local original DB, each PC makes the time (for example, the time notified by the server) inquired of the server (regardless of whether or not editing has not been received and its validity) as the version of the local original DB.

When the server updates the global original DB, the time of the access from a PC is used as the version of the original DB, and if necessary, it is synchronized with the local original DB and the global original DB of the PC and simultaneously (That is, the latest access time) is also synchronized. Since editing to a local original DB with a newer synchronous access is given priority, it is a rule that can be easily understood and understood by those who operate one DB in competition.

(5) Replication range of local original DB To simplify the description of the present application, it is convenient that the local original DB is synchronized with the entire (virtual or real) global original DB. However, considering actual use, it is more realistic that the local original DB is synchronized with a part of the global original DB. For example, the medical information DB described above has a large amount of personal information. Of these, it is sufficient to create a local original DB for personal information in a range that can be read with the authority for each PC, and the local original DB does not need to be synchronized with the entire global original DB. The doctor's computer has a local original DB that holds information on the patient (several) patients, and the personal computer has a local original DB that holds only the personal information of the person.

When the local original DB is synchronized with only a part of the global original DB, many editing records collected on the server are not necessary for a specific PC. One method is to skip unnecessary editing records after all editing records are received by the PC. If the necessary edit records are extracted and sent for each PC on the server side, the amount of communication is reduced and hacking to unauthorized information is also prevented. For example, even if unnecessary editing records remain, they can be excluded by processing on the PC side. If the edit records managed by the server are classified based on the version setting range recorded in the edit information, the edit records to be sent to the PC can be quickly determined.

(6) In the explanation of the operation destination with update cancellation, “operation without update cancellation” was dealt with. However, if the principle that the edit version prioritizes the new edit is strictly applied, (Y becomes valid condition 2 ), The update by X may be canceled before the update of “local original DB” by Y. This is a case where the “edit cancellation condition” of “(x <) y <nx” is satisfied.

(6.1) Cancellation analysis 1
In order for Y to cancel a past update (X above), at least all of the following conditions must be satisfied. The following (X update cancellation conditions 3 and 4) correspond to the “edit cancellation conditions” described above.
(X update cancellation condition 1) Y is not invalidated by another editing record.
(X update cancellation condition 2) X updated the invariant confirmation range of Y.
(X update cancellation condition 3) “x <y”. After Y edit version X. If this is not true, Y is invalid and does not become a canceling factor for X.
(X update cancellation condition 4) “y <nx”. Before the version update by X is transmitted, the local original DB to be edited by Y is updated (to y).

In addition to this condition, the timing of X being canceled is related to the timing of Y's up to the server. If the Y-up is before the X-up (nx), X is determined to be invalid when the “local original DB” is updated by X, and the cancellation is not canceled.

Update records for invalidating X are limited by (X update cancellation condition 1). In other words, an edit whose edit version is determined to be invalid is not a factor for canceling the previous edit.

(X update cancellation condition 2) indicates that the designation of the invariant confirmation range affects the possibility of update cancellation. By not increasing the invariant confirmation range carelessly, the possibility of canceling the update can be reduced.

(X update cancellation conditions 3 and 4) is the X editing period, that is, “while X is updated to the server after the version of the local original DB to be edited X is updated (to x)” In this case, the version of “local original DB” is updated (to y), and this is the editing target of Y. The possibility of canceling X can be reduced by speeding up editing (X) by X PC.

(6.2) Update cancellation prevention method There are cases where it is desirable to prevent update cancellation, such as changing the structure of the database.

(Prevention of reversal of update # 1: No upload)
If editing from another PC is not uploaded during the editing period of X, even if another PC updates (Y) its local original DB during this period, the version will only be x, and it will not be later than x. No. That is, (X update cancellation condition 3) is not satisfied. If the local original DB is updated (Y) after X is up (nx), (X update cancellation condition 4) is not satisfied. That is, if the uploading from another PC is prohibited during the editing period of X, cancellation of X can be prevented.

(Update cancellation prevention method 2: Update prohibited)
Even if editing from another PC is uploaded during the editing period of X, cancellation of X can be prevented if other PCs are prohibited from updating the local original DB. It is one method not to send an edit record from the server, and even if an edit record is sent, a method of prohibiting updating (Y) of the local original DB by the edit record may be used.

After X is up, any PC can attempt to update the local original DB again. At this time, since X is included in the edit record fetched from the server, the version becomes nx or later if the local original DB is updated to the end of the fetched edit record. In the PC in which the update of the local original DB is prohibited, the prohibition is canceled after X arrives, the local original DB is updated using X, and the version is nx or later. Therefore, the version of the edit record for these is nx <y, and the “edit cancellation condition” does not occur.

In the case of the method using “synchronous access time to server” as the version, the same effect can be obtained by not returning the access time by returning “access locked” from the server to the request from the PC. It is done.

(Prevention of update cancellation part 3: Editing prohibited)
Even if editing from another PC is uploaded during the editing period of X and the other PC updates the local original DB, cancellation of X can be prevented by prohibiting editing on the updated local original DB. When an edit record is sent from the server, for example, the prohibition of edit to the local original DB updated by the edit record is notified.

(6.3) Analysis of update cancellation, part 2
When the update by a certain editing record (X mentioned above) is cancelled, the following processing is necessary to perform the cancel perfectly.
(Process 1 Derived from Cancellation) The presence / absence of the edit record invalidated by X is investigated, and if it is valid, the validity / invalidity is re-evaluated.
(Process 2 Derived from Cancellation) If there is information that the operator has entered again with reference to the editing record invalidated by X, the input is reviewed.
(Process 3 Derived from Cancellation) The validity of the editing record in which editing based on the update by X, that is, the version set after the update by X is used as the edit version is re-evaluated.

It is possible to automatically execute a part of the above (Process 1) and (Process 3). However, since there are parts that require the cooperation of the operator, such as (Process 2), complete automatic execution is difficult. After canceling X, the derivation process of (Process 1), (Process 2), and (Process 3) is not executed, but the cancellation fact of X is accurately communicated to the operator, and then re-input is made at the operator's discretion. Is realistic. If the fact of invalidity, its object and reason are clearly communicated, the operator can respond reasonably.

By not performing the cancellation derivation process, the determination that X is invalid is not covered again. Accordingly, in response to this, the operator can perform an appropriate operation such as re-input.

(7) Even when information addition and deletion information is newly created, an edit record is created, and the version of the target DB at that time is recorded as an edit version. Even when deleting DB information, “deletion target, fact of deletion, influence range, version” is set as an edit record. Since this editing (deletion) may become invalid, it cannot be actually deleted from the local original DB at this stage. It is possible to actually delete it after it is determined to be valid.

(7.1) Supplementary information regarding information addition In order to set a primary key (ID) in a record in the RDB, the key must not overlap with other records. In parallel DB access, consideration for this is necessary. That is, a situation in which a record with the same primary key exists cannot be caused by a plurality of PCs adding records in parallel.

In the case where the server updates the global original DB, if the primary keys given by the PCs to the new record collide, the problem is solved by replacing them so that there is no duplication. When the PC synchronizes the copy DB at hand with the original DB, the new primary key information is transmitted.

When there is no global original DB and each PC updates the local original DB, there are several methods for avoiding a primary key collision.

(Primary key duplication avoidance method 1)
By previously assigning a range of primary keys that can be newly assigned to each PC from the server or management PC, it is possible to avoid collision of primary keys of new records. A method of preventing a collision by using a UUID as a primary key is also possible.

(Duplicate primary key avoidance method 2)
A record (K) for recording the next primary key is set in the DB. This K value is used as the primary key of the newly created record (Z), and then the K value is updated. If the update of K is enabled in accordance with the “prioritize editing for more recent information” rule, the addition of the record is complete, but if it is determined to be invalid, the update of the K value is disabled. The addition of record (Z) is also treated as invalid.

(Primary key duplication avoidance method 3)
When a collision of a primary key of a new record is detected when the “local original DB” is updated by the edit record, the edit version of the new edit record is adopted. This means that even if it is determined to be valid by checking the edited version, there is a case where it is further determined to be invalid by the content check. Further studies are needed to ensure the integrity of the information.

<< Correspondence with Claims at Filing >>
The process of updating the original DB (global original DB or local original DB) is common to the case where each PC updates its local original DB and the case where the server updates the global original DB. This is shown in claim 1. The term database is used as a concept including a global original DB, a duplicate DB, a local original DB, a work DB, and the like. This method "prioritizes editing based on the latest information" is not only a full-fledged "parallel DB editing" in which the computer permanently holds the replication DB, but also the computer temporarily holds the replication DB It is also effective in cases where

Claim 2 specifies the database version update process. Claim 3 specifies the concept of the version setting range. Here, it is simply referred to as “specified range of information”, but various specification methods are assumed, such as when specified in advance by the system or when specified for editing records. It is not limited to the method.

Claim 4 corresponds to a method of using the time when the server accepts the edit record, or a method of using the synchronous access time to the server instead of the version. This does not limit the method of specifying the “specified time”. The fifth aspect corresponds to an operation in which update is canceled, and steps D and E are inserted between steps B and C. Claim 6 specifies the concept of “invariant confirmation range” in claim 1.

Claim 7 corresponds to the case where the global original DB is updated in the server. In addition to claim 1, a process F for transmitting information of the global original DB updated from the server to each PC is added. The time when the edit record arrives at the server is used as the database version.

On the basis of claim 2, claim 9 adds the synchronous access time to the server as the version of the local original DB. The tenth aspect of the present invention adds the time of downloading the edit record from the server to the updated version of the local original DB. On the basis of claim 1, claim 11 includes a step of notifying other computers of “stop of editing, stop of editing up, or stop of updating of local original DB”.

If an attempt is made to perform parallel DB editing by extension of the conventional cache technology, a copy is created for each editing, and there is a problem in that the copy processing and communication become overhead. This problem is solved by a method of permanently using the local original DB for each PC. The local original DB is updated based on the edit record created by each PC. Note that it is not necessary to create a local original DB that duplicates all of the enormous DB, and a local original DB that holds only a part necessary for the computer is sufficient.

In the “first-come-first-served” method based on the conventional cache technology, there were cases where the judgment based on the latest information was invalid, but based on the policy of “prioritizing editing based on the latest information” of the present invention. The method solves these problems.

In the conventional “prior editing priority” method, editing that is determined to be valid at a certain point in time may be invalidated by editing that arrives later, which is an operational problem. However, there is no problem if the “operation without cancellation of update” of the present application is used. Even in the “operation with update cancellation” of the present application, cancellation occurs in a very limited situation. The possibility of cancellation can be reduced by shortening the period of editing the local original DB in synchronization and uploading the edit record.

The criterion of “prioritizing editing based on the latest information” according to the present invention is an idea that “a judgment based on the latest information is more likely”, and is a criterion that is easily accepted by humans who handle data.

According to the concept of the version setting range of the present invention, management of updating information becomes clear as in the case of dividing a DB without actually dividing the DB. Furthermore, only the conflict that should be resolved can be accurately detected by the concept of “invariant confirmation range”.

By setting the version of the local original DB to the date and time when the last applied edit record was accepted by the server, or the date and time when the computer checked for the presence of the edit record (last) Operation with greater emphasis on “priority editing” is possible.

In the present invention, a mechanism for preventing cancellation of update by editing, editing up, and stopping update of the local original DB has been clarified.

General computer configuration Case of updating local original DB of PC Procedure for updating the local original DB (part 1) Update procedure of local original DB (2) The case of updating the server's global original DB Global original DB update procedure (1) Global original DB update procedure (2) Procedure to tell server to PC from prohibition of upload Procedure to inform the PC that editing is prohibited Simplified example

0100 Calculator
0102 Communication device
0103 Arithmetic unit
0104 Main memory
0105 DB (database) in main storage
0106 secondary storage
0107 I / O device
0108 display device
0109 Bus
0110 communication network
0111 DB (database) in secondary storage
0201 PC
0202 Communication network such as the Internet
0203 server
0204 (PC) storage device
0205 (server) storage device
0206 Local original DB
0207 Global Early Original DB
0208 Editing record
0209 Work DB
0210 Editing record n
0210 Editing record n + 1
0211 Editing record
0213 Editing means
0214 Update means
0215 Transmission means
0216 Receiving means
0217 Transmission / reception management means
0218 Editing record 1
0219 Editing record m
0220 Transmission means
0221 Receiving means
0222 Transmission / reception management means
0301 Receive unedited edit record
0302 Enter the list of unprocessed edit records
0303 Take one edit record (Y) from the unprocessed edit record list
0304 Extract edit version (y) and invariant confirmation range from edit record (Y) to be processed
[0305] Extract past edit record (X) whose information of invariant confirmation range has been changed
[0401] The edit version (x) of the past edit record (X) is compared with the edit version (y) of the edit record (Y) to be processed.
0402 Compare x and y
[0403] Past edit records (X) whose information of the invariant confirmation range has been changed are extracted in order (again).
[0404] The updated version (nx) of the local original DB is specified by the past editing record (X) taken out.
0405 Compare nx and y
[0406] Cancel the update of the local original DB by the extracted past edit version (X)
0407 Update local original DB with edit record (Y) to be processed
0408 Update local original DB version
0501 PC
0502 Communication networks such as the Internet
0503 server
0504 (PC) storage device
0505 (server) storage device
0506 Local original DB
0507 Global Original DB
0508 Editing record
0509 Work DB
0510 Local original DB update information
0511 Editing means
0512 Update method
0513 Transmission means
0515 Receiving means
0515 Transmission / reception management means
0516 Local original DB update information
0517 Update means
0518 Transmission method
0519 Receiving means
0520 Transmission / reception management means
0601 Edit record received
0602 Extract edit version (y) and invariant confirmation range from edit record (Y) to be processed
0603 Takes out past edit record (X) in which information of immutable confirmation range was changed
[0604] The editing version (x) of the past editing record (X) taken out is compared with the editing version (y) of the editing record (Y) to be processed.
0605 Compare x and y
0701 Retake past edit records whose information in the invariant confirmation range has been changed again.
0702 The version (nx) of the updated global original DB is specified by the past editing record (X) taken out
0703 Compare nx and y
0704 Cancel the update of the original clobber DB with the past edited version (X)
0705 Update local original DB with edit record (Y) to be processed
0706 Update the global original DB version
0801 Receive edit record transmission request (with last last number)
0802 Confirmation when uploading is prohibited
0803 Notify up prohibition
0804 Create a list of edit records that have not been sent yet, that is, after the last number
0805 Send
0806 Completion notification
0901 Received edit record send request (with last last number)
0902 Create a list of unsent edit records
0903 send
0904 Judgment when editing is prohibited
0905 Notify editing prohibited
0906 Completion notification
1002 PC-A
1003 PC-B
1004 Initial DB
1005 Local original DB update (of PC-A)
1006 Local original DB update (of PC-B)
1008 Copy of record Z (PC-A)
1009 Copy of record Z (PC-B)
1010 Acquisition of global initial original DB (by PC-A)
1011 Acquisition of global initial original DB (by PC-B)
1012 Synchronization (by PC-A)
1013 Editing (by PC-A operator)
1014 Send edit (by PC-A). In other words, editing is up.
1016 Confirmation (notification to PC-A) and synchronization (by PC-A). The synchronization is new editing and acquisition of the order thereof, and the same applies to the description of other symbols.
1017 Synchronization (by PC-B)
1018 Editing (by PC-B operator)
1019 Send edit (by PC-B). In other words, editing is up.
1021 Confirmation (to PC-B) (notification) and synchronization (by PC-B).
1022 Synchronization (by PC-B)
1023 Correction (of PC-A record Z copy based on PC-B edit)

The method of the present invention can be realized as a computer program. FIG. 1 shows the configuration of a typical computer 0101. An arithmetic device 0103, a main storage device 0104, a secondary storage device 0106, an input / output device 0107, and a display device 0108 are connected by a bus 0109. When exchanging data with another computer, it connects to the communication network 0101 via the communication device 0102. The “database” mentioned in each claim is the DB 0111 in the secondary storage device 0106 or the DB 0105 in the main storage operation 0104.

The program is recorded in the secondary storage device 0106. When the program is activated, the program is expanded to the main storage operation 0104, and the arithmetic unit 0103 operates according to the procedure specified in the program. As a result, the computer is reconfigured into a collection of means for realizing the operation intended by the program developer.

In general, a DB operation by a program is performed after all or a part of the DB is expanded to the main memory operation 0104. The DB 0105 in which all or part of the DB 0111 in the secondary storage device 0106 is expanded to the main memory operation 0104 is operated, and the editing result is written in the DB 0111 in the secondary storage device 0106. However, normally, it is assumed that the DB is in the secondary storage device 0106 and will be discussed without distinction from the DB 0105 expanded in the main storage operation 0104. Therefore, in FIGS. Display as the middle DB.

A case in which edit records created by a plurality of PCs 0201 are collected by the server 0203, the PC 0201 receives the edit records collected by the server, and the local original DB 0206 of the PC is updated will be described with reference to FIG. A PC 0201 is connected to a server via a communication network 0202 such as the Internet. In general, there are a plurality of PCs, but only one is shown in FIG.

The PC 0201 has a storage device 0204, in which a local original DB 0206 is recorded. The initial value of the local original DB 0206 is a copy of the global initial original DB 0207 of the storage device 0205 of the server 0203. The editing unit 0213 performs editing in response to an instruction from the operator of the PC 0201. At this time, the local original DB 0206 is not directly edited, and the editing result is set as the work DB 0209. At the same time, edit record 0208 is created. In this edit record, an edit version, that is, a version set in the local original DB is recorded.

The edit record 0208 is sent to the server 0203 via the communication network 0202 by the transmission means 0215. The server 0203 is received by the receiving means 0221 and added to the edit record 10218 and edit record m0219 columns. It is assumed that an edit version is recorded in the edit record. If an edit version is sent to the server separately from the edit record, the server records their correspondence.

When the PC 0201 attempts to update the local original DB 0206, it first requests the server to transmit an unreceived edit record. When the PC 0201 notifies the last version of the edit record received so far, the transmission / reception management unit selects the subsequent edit record and sends it from the server by the transmission unit 0220. The PC transmission / reception cooperative work is performed by the transmission / reception management unit 0217, and the server transmission / reception cooperative work is performed by the transmission / reception management unit 0222.

The edit records 0210, 2011, 0212 received by the receiving unit 0216 by the PC 0201 are recorded in the storage device 0204. The update unit 0214 extracts them in order, determines the validity, updates the local original DB 0206, and updates the version.

The update procedure of the local original DB 0206 by the update unit 0214 of the PC 0201 in FIG. 2 is shown in FIGS. The PC 0201 first receives “unreceived edit record” 0301 and then “enters the unprocessed edit record list” 0302. This is repeated for all unreceived editing records. The list of unprocessed edit records corresponds to edit record n0210, edit record n + 1021, and edit record m0212 in FIG.

Next, “Extract one edit record (Y) from the unprocessed edit record list” 0303, “Extract edit version (y) and invariant confirmation range from edit record (Y) to be processed” 0304, and “Invariant” Extract past edit record (X) whose confirmation range information has been changed ”0305,“ Compare edit version (x) of past edit record (X) and edit version (y) of edit record (Y) to be processed 0401. If “compare x and y” 0402, and y <x or y = x, the edit record (Y) to be processed is invalidated and the update process is not performed. Then, it moves to the next unprocessed editing record (goes to 0303).

In the case of y> x, since Y is valid for X, the process proceeds to the investigation of the next past edit record (moves to 0305). “Identify past edit record (X) whose invariant confirmation range information has been changed” 0305 is completed, and when the unprocessed edit record (Y) is valid for all, it is determined to be valid and the next process (Go to 0403)

Next, “retrieve editing records (X) in which the information of the invariant confirmation range has been changed is retrieved in order (again)” 0403. If there is, “specify the version (nx) of the updated local original DB from the past editing record (X) taken out” 0404. “Compare nx and y” 0405, and when y <nx, “cancel update of local original DB by extracted past edit version (X)” 0406.

“Retrieve past edit records whose information in the invariant confirmation range has been changed” 0403 After all past edit records are extracted and processing is completed, “Update local original DB with edit record (Y) to be processed” 0407 and “update the version of the local original DB” 0408.

If the version setting range is specified and it matches the invariant confirmation range, the procedure is as follows. It is assumed that the version setting range is specified in the edit record. “Specify edit version (x) of past edit record (X) taken out and edit version (y) of edit record (Y) to be processed” 0401 In process 0401, it is designated as the edit record (Y) to be processed For the version setting range that is present, “specify edit version (x) of past edit record (X) and edit version (y) of edit record (Y) to be processed”. And later versions are compared against this.

In the case of operation using the version when the server receives the edit record, the server records the reception time in the edit record. Then, in “update the version of the local original DB” 0408, the PC records the reception time recorded in the editing record used for the update as the updated version of the local original DB 0408.

If the PC accesses the server, obtains the time from the server to confirm whether there is an unreceived edit record, and uses the time as the version of the original DB, “Receive unreceived edit record” 0301 Get the access time to the server before, during, or during "Entering the list of unprocessed edit records" 0302. Considering the time lag for each PC, it is desirable to receive this time from the server. Then, this time is recorded, and after updating the local original DB 0407 with the last editing record of the received editing record, the recorded time is recorded as a version of the local original DB 0408.

A case where the global original DB is updated by the server will be described with reference to FIG. A PC 0501 is connected to a server 0503 via a communication network 0502 such as the Internet. In general, there are a plurality of PCs, but only one is shown in FIG.

The PC 0501 has a storage device 0504, in which a local original DB 0506 is recorded. The editing unit 0511 performs editing in response to an instruction from the operator of the PC 0501. At this time, the local original DB 0506 is not directly edited, and the editing result is the work DB 0509. At the same time, edit record 0508 is created. In this edit record, an edit version, that is, a version set in the local original DB is recorded.

The edit record 0508 is sent to the server 0503 via the communication network 0502 by the transmission means 0513. The server 0503 receives the reception unit 0519, determines the validity with the version recorded in the editing record, and updates the global original DB 0507. At this time, local original DB update information 0516 is created. The local original DB update information 0516 is sent to the PC 0501 by the transmission means 0518 of the server, received by the reception means 0514, and recorded in the storage device 0504. The updating unit 0512 updates the local original DB 0506 using the local original DB update information 0510. Coordination work for PC transmission reception is performed by transmission / reception management means 0515, and server transmission reception cooperation work is performed by transmission / reception management means 0520.

The procedure for updating the global original DB on the server 0503 is shown in FIGS. “Receive edit record” 0601 from PC 0501 and “take out edit version (y) and invariant confirmation range from edit record (Y) to be processed” 0602. Then, “Retrieve past edit record (X) whose information of invariant confirmation range has been changed” 0603, “Edit version (x) of retrieved past edit record (X) and edit record (Y) to be processed Compare version (y) "0604. “Compare x and y” 0605. If y <x or y = x, the edit record (Y) to be processed is invalidated, and the update process is not performed.

In the case of y> x, since Y is valid for X, the process proceeds to the investigation of the next past editing record (moves to 0603). When “Extract past edit record (X) whose invariant confirmation range information has been changed” 0603 is all completed and unprocessed edit record (Y) is valid for all, it is determined to be valid and the next process (Go to 0701)

Next, “retrieve past edit records in which the information of the invariant confirmation range has been changed again in order” 0701. If there is, “specify the version (nx) of the updated global original DB by the extracted past editing record (X)” 0702. “Compare nx and y” 0703, and if y <nx, “cancel update of global original DB by retrieved past edit version (X)” 0704.

“Retrieve past edit records whose information in the invariant confirmation range has been changed” 0701. After all the past edit records are extracted and the processing is completed, “Update local original DB with edit record (Y) to be processed” 0705, and “update the version of the global original DB” 0706.

FIG. 8 illustrates a procedure for transmitting “up prohibition” from the server to the PC for preventing update cancellation. When the server receives “edit record transmission request (with last last number) received” 0801 from the PC, the server determines whether it is “up prohibited” 0802. Based on a request from a certain PC, if the server is in the state of prohibiting up, “notify up prohibition” 0803 is sent to the PC that has requested transmission of the edit record. If the upload is not prohibited, “unsent, that is, create a list of edit records after the last final number” 0804, “send” 0805 to the PC, and finally send “completion notice” 0806.

FIG. 9 illustrates a procedure for transmitting “edit prohibited” from the server to the PC for preventing update cancellation. When “Receiving edit record transmission request (with last last number)” 0901 from the PC, the server “creates a list of edit records that have not been sent (that is, after the last last number)” 0902 and sends these to the PC. Send "0903. After this, the server determines whether the editing is “prohibited editing (in the local original DB)” 0904. If updating is prohibited based on a request from a certain PC, “notify editing prohibited” 0905 is sent to the PC that has requested the editing record transmission, and finally “completion notification” 0906 is sent.

<Simplified embodiment>
FIG. 10 shows another embodiment. The DB in FIG. 10 is an RDB, the version setting range is the entire DB, the version is an integer, the invariant confirmation range is only the edited record, and “operation without canceling update” is set.

In addition, the edit version at the time of editing this record is recorded as “record version” for each record. Thus, only by comparing the version of the record to be edited and the edited version (y) of the edit record (Y) to be processed, “retrieve past edit record (X) whose invariant confirmation range information has been changed” is extracted. The process of “Compare the editing version (x) of the past editing record (X) with the editing version (y) of the editing record (Y) to be processed” 0401 can be performed.

Although simplified in this way, it is convenient to see the changes in version. In FIG. 10, the global initial original DB, the edit record, and the arrival order (up order) are recorded on the server. The vertical axis of the server shows the most recent edit at that time.

The PC-A 1002 and the PC-B 1003 acquire the global initial original DB 1004 1010 and 1011 respectively, and use them as the local original DBs 1005 and 1006, respectively. Since the global initial original DB 1004 of the server is copied, the base version of both is 0. Thereafter, edits 1 to 6 are uploaded to the server 1001, which is an edit uploaded by a PC- other than the PC-A 1002 and PC-B 1003.

In FIG. 2, the PC-A 1002 accesses the server once again, and acquires the order of the latest editing at that time 1012. At this time, since edit 1 is captured, the version of the local original DB 1005 becomes 1.

Now, let us say that the operator of the PC-A 1002 has edited the copy 1008 of the record Z in the local original DB 1005 1013. At this time, since the base version of the local original DB 1005 is 1, the edited record version of “replicated record Z 1008” is set to 1. This edit record is uploaded to the server and recorded as 1014 and edit 7. Immediately after this, PC-A 1002 acquires edit 6 from edit 2 that has been uploaded after edit 1 (which has already been acquired), and confirms that up 1014 ahead of PC-A 1002 is now edit 7. To do. Based on the “determination of the validity of editing” designated in advance, the editing up to editing 7 is investigated in order, and the local original DB 1005 is updated. Here, assuming that edit 7 is valid, the base version of the local original DB 1005 is 7.

On the other hand, the PC-B 1003 acquires from the server 1001 the edit 6 (latest at the time of this synchronization 1017) 1017 and updates the local original DB 1006 to the base version 6. Thereafter, it is assumed that the operator of the PC-B 1003 has edited 1018 “duplicate record Z 1009”. At this time, the record version of “duplicate record Z 1009” becomes 6, and the edit record is uploaded to the server 1019 and recorded as edit 8.

Then, after the editing 9 is uploaded from another PC-, the PC-A 1002 accesses the server 1001, and acquires the editing 8 and the editing 9 uploaded after the editing 7 (already acquired) 1022. Then, edit 8 and edit 9 are applied to the local original DB 1008 in order, “edit validity determination” is performed, and the local original DB 1008 is updated. Here, since the edit 9 is reflected in the local original DB 1008, the base version of the manufactured DB 1008 becomes 9. At this time, the contents of the record Z replica 1009 edited by the PC-B 1003 become valid in the local original DB 1005 of the PC-A 1002, and the contents of the record Z duplicate 1008 edited by the PC-A 1002 become invalid. It turns out (by PC-A1002).

It is convenient to edit a database from multiple computers in parallel, but the problem is parallel conflict resolution. The conflict resolution method of the present application is a mechanism that “priorizes editing based on the latest information”, and even in full-fledged “parallel DB editing” in which a computer permanently holds a replication DB, the computer temporarily stores the replication DB. It is also effective in cases where This method has a feature that “editing based on old information is determined to be invalid”. When editing information that is expected to conflict, it is possible to reduce the possibility that this editing will be invalidated by “almost online operation” that quickly performs “synchronization with the latest information, editing, and sending of edit records”. I can do it. Conversely, when editing information for which no conflict is expected, “almost offline operation” in which editing is performed slowly after information synchronization and the editing records are sent together may be used. The method of the present application enables parallel editing of databases in a wide range of application fields.

Claims (5)

A method for editing a database replica (hereinafter referred to as “Duplicate Database”) ,
(1) versions for the duplicate database (ordinal number to be updated with the update of the replicated database) is recorded,
(2) the recording of the editing intended for working copy of the replicated database (hereinafter "Edit recording"), the version value (hereinafter "edit version of the replicated database at the time of creating the copy the work )) Is recorded,
(3) The plurality of edit records for updating the duplicate database include edit records for other duplicates of the database,
And (Step A) already editing recorded value of edited version that was recorded with respect to edited record that was used to update the said replicated database, for a new edit recording (hereinafter "new editing records") Compare version values (hereinafter “new version”)
If (step B) those of the "new version" is new, and update the duplicate database by using the "New Edit Record", to update the version that has been recorded with respect to the replicated database,
If (step C) towards the "new version" is older, update of the replicated database using the "New Edit Record" is not performed,
A method characterized by a series of steps. A method for editing a database replica (hereinafter referred to as “Duplicate Database”) ,
(1) versions for the duplicate database (ordinal number to be updated with the update of the replicated database) is recorded,
(2) the recording of the editing intended for working copy of the replicated database (hereinafter "Edit recording"), the version value (hereinafter "edit version of the replicated database at the time of creating the copy the work )) Is recorded,
(3) The plurality of edit records for updating the duplicate database include edit records for other duplicates of the database,
Further edited to (Step A) range of information that has been specified for the edit recording (hereinafter "new editing records") used for updating of the duplicate database (hereinafter "invariant check range"), which is applied to the far and compares the value of the editing version that had been recorded for the record, the value of the edited version that was recorded for該新editing records (hereinafter referred to as the "new version"),
If (step B) those of the "new version" is new, and update the duplicate database by using the "New Edit Record", to update the version that has been recorded with respect to the replicated database,
If (step C) towards the "new version" is older, update of the replicated database using the "New Edit Record" is not performed,
A method characterized by a series of steps. A method for editing a database replica (hereinafter referred to as “Duplicate Database”) ,
(1) Version against a portion of the replicated database information (hereinafter "Version Range") (the number of the order to be updated with the update of the contents of the version set range) is recorded,
(2) the recording of the editing intended for working copy of the replicated database (hereinafter "Edit recording"), the value (hereinafter "Editing of the version of the version set range at the time of creating the copy the work Version ") is recorded,
(3) The plurality of edit records for updating the duplicate database include edit records for other duplicates of the database,
And (Step A) already editing recorded value of edited version that was recorded with respect to edited record that was used to update the said replicated database, for a new edit recording (hereinafter "new editing records") Compare version values (hereinafter “new version”)
If (step B) those of the "new version" is new, when you update the replicated database by using the "new editing records", the contents of the "version Setting range" has been changed, the " Update the version recorded for “Version setting range”
If (step C) towards the "new version" is older, update of the replicated database using the "New Edit Record" is not performed,
A method characterized by a series of steps. A method for editing a database replica (hereinafter referred to as “Duplicate Database”) ,
(1) versions for the duplicate database (time information which is updated with the updating of the duplicate database) is recorded,
(2) the recording of the editing intended for working copy of the replicated database (hereinafter "Edit recording"), the version value (hereinafter "edit version of the replicated database at the time of creating the copy the work )) Is recorded,
(3) the editing record, is transmitted to the device that relays the editing records (hereinafter referred to as "server"),
(4) Editing recording unreceived received from the server, the presence or absence of editing records of unreceived receive time confirming to the server from the server, the value of the version of the database,
And (Step A) already editing recorded value of edited version that was recorded with respect to edited record that was used to update the said replicated database, for a new edit recording (hereinafter "new editing records") Compare version values (hereinafter “new version”)
If (step B) those of the "new version" is new, by using the "New Edit Record" to update the replicated database, and set the "new version" as the value of the version of the plurality party database ,
If (step C) towards the "new version" is older, update of the replicated database using the "New Edit Record" is not performed,
A method characterized by a series of steps. A method for editing a database replica (hereinafter referred to as “Duplicate Database”) ,
(1) versions for all or a portion of the replicated database (ordinal number to be updated with the update of the replicated database) is recorded,
(2) the recording of the editing intended for working copy of the replicated database (hereinafter "Edit recording"), the version value (hereinafter "edit version of the replicated database at the time of creating the copy the work )) Is recorded,
(3) The plurality of edit records for updating the duplicate database include edit records for other duplicates of the database,
And (Step A) already editing recorded value of edited version that was recorded with respect to edited record that was used to update the said replicated database, for a new edit recording (hereinafter "new editing records") Compare version values (hereinafter “new version”)
(Step B) When the “new version” is newer, the duplicate database is updated using the “new edit record”, and the value of the version recorded in the duplicate database is updated.
A method characterized by a series of steps.

Images