JP4314126B2 - Concurrent execution control method and apparatus - Google Patents

Description

  The present invention relates to a database system that performs simultaneous execution control of update processing and reference processing (search processing).

  Conventionally, database transactions (processing units consisting of update, reference (search), etc.) are managed in a database system by concurrent execution control. This concurrency control is intended to guarantee data consistency by performing exclusive control when multiple users try to access the same data in the database system at the same time, that is, access such as update and reference. is there.

  Normally, in a database, when a transaction tries to access data, a lock such as a private lock or a shared lock is applied to restrict access to other transactions. Normally, with a two-phase lock, locks are made sequentially before data operations at the start of a transaction, and the lock is not released until the end of the transaction. In such a lock method, access to other transactions is restricted, and thus a problem that a search transaction is waited for by an update transaction occurs.

In the multi-version method, the update transaction is updated after copying the data to be updated, so that other search transactions can simultaneously access the replicated data (see, for example, Patent Document 1 and Patent Document 2). .
JP-A-6-28315 JP 2003-140951 A

  Conventionally, when concurrent execution control of update and reference (search) is performed by the multi-version method, it is necessary to maintain the state of the database before update and after update for the search process that occurs before and after the update process, respectively. There is a problem that the storage capacity required for the process becomes enormous.

  Accordingly, in view of the above problems, the present invention provides a simultaneous execution control method and apparatus capable of easily performing simultaneous execution control of update and reference (search) while minimizing the amount of data to be stored. With the goal.

  The present invention relates to a first data group that is one of a plurality of data groups to which identifiers are given, and a first data group before update including data before update and after update including data after update. The first data group is stored in a separate storage area, and a plurality of index words and an identifier of a data group corresponding to one of the plurality of index words and having data including the index word Is selected from among a plurality of registered tables, and (a) the table group is selected before the update of the first data group is completed. The first table corresponding to the first index word included only in the first data group before the update of the first data group before and after the update, and the first data group before and after the update The second included only in the first data group after updating When at least the first table of the second table corresponding to the index word is included in the table group, the first data group before update is output as a search result, and (b) the first table When the table group is selected after the update of one data group is completed, when the first time that is the time when the search request is received is before the second time that is the start time of the update, When the table group includes at least the first table of the first and second tables, the first data group before update is output, and the first time is later than the second time. In some cases, when the table group includes at least a second table of the first and second tables, the updated first data group is output as a search result.

  Simultaneous execution control of update and reference (search) can be easily performed while minimizing the amount of data to be stored.

  FIG. 1 shows a configuration example of an information management apparatus to which the simultaneous execution control apparatus according to this embodiment is applied. As shown in FIG. 1, the information management apparatus 1 includes an update processing unit 2, a commit processing unit 3, a reference processing unit 4, a version data management unit 5, a time management unit 6, and a table storage unit 10, and further includes an indexing unit. A database 20 having a data storage unit 21, a map table storage unit 22, and an object data storage unit 23 is connected.

  A plurality of (in this case, for example, two) terminals TE1 to TE2 are connected to the information management apparatus 1 via a predetermined network or the like, and receives requests such as data update, data reference, and data commit from the terminal.

  In response to a data update request from the terminal, the update processing unit 2 accesses the database 20 and updates object data and index data.

  In response to the commit request from the terminal, the commit processing unit 3 performs a process for confirming the update content performed via the update processing unit 2. Here, commit is synonymous with update confirmation.

  The reference processing unit 4 receives a data reference request (including a keyword for searching for object data) from the terminal, searches the object data storage unit 23 for object data including the keyword, and transmits it to the requesting terminal. To do.

  The time management unit 6 stores and updates the time incremented by “1” every time the update process ends (every commit process ends).

  The table storage unit 10 stores an update log table 11, a version data table 12, and a reference log table 13.

  The object data storage unit 23 stores a plurality of object data to be updated / referenced (searched). Object data is specified by a logical object ID and a physical object ID. The logical object ID is an object ID that does not consider the physical object placement location. The logical object ID is an object ID calculated from a physical object arrangement location (a position where the object data is stored in a storage area corresponding to the object data storage unit 23). Usually, the occurrence position in the index data is expressed by a logical object ID. The conversion from the logical object ID to the physical object ID is performed using a map table stored in the map table storage unit 22.

  FIG. 2 schematically shows an example of storing object data in the object data storage unit 23. One object data is configured by linking a plurality of data (element data) according to their order relationship (or vertical relationship).

  The object data storage area in the object data storage unit 23 is composed of a plurality of slots which are storage areas for storing element data constituting the object data. Each slot is specified by a slot ID. Therefore, each element data is specified by the logical object ID of the object data including the element data (or the physical object ID corresponding to the logical object ID) and the slot ID of the slot in which the element data is stored.

  For example, the object data stored in the physical object ID “POID5” of the object data storage unit 23 is configured by connecting two element data “memory” and “database” in this order. The element data “memory” and “database” are respectively stored in slots with slot IDs “SLOT0” and “SLOT1”. The object data stored in the physical object ID “POID6” of the object data storage unit 23 is configured by connecting two element data “XML” and “data” in this order. The element data “XML” and “data” are respectively stored in slots with slot IDs “SLOT0” and “SLOT1”. As described above, each object data has a data structure in a list format.

  The first slot of each object data storage area stores pointer information (for example, the slot ID of the first element data) to the first element data slot of the list, and each slot stores the next element data. Pointer information (slot ID) to a slot is stored together with element data. Therefore, each element data of the list can be traced by following the chain based on the pointer information.

  FIG. 3 schematically shows an example of storage of index data stored in the index data storage unit 21. Here, the index data is an index word composed of at least a numerical value (including date and time), a word, and a vocabulary, a logical object ID of object data having element data including the index word, and a slot ID of the element data. Are associated with each other. That is, it is data for finding out element data and object data having the index word (where the index word is generated) from the index word.

  In FIG. 3, the index data includes a “vocabulary” field and an “occurrence position table” field. In the “vocabulary” column, a plurality of index words are registered. For each vocabulary, a logical object ID and a slot ID, and information indicating whether the element data specified by the logical object ID and the slot ID is deleted or inserted by update A generation position table in which information indicating whether or not it is necessary to check whether or not the element data is actually stored in the object data storage unit 23 and an update time is registered.

  For example, one occurrence position table is associated with each of the index words “memory” and “database” in the “vocabulary” column. In the occurrence position table, element data including the index word and this data The generation position data indicating the generation position in the object data of the element data is registered.

  As shown in FIG. 3, the occurrence position table includes an “occurrence position” field, a “deletion / insertion” field, a “confirmation necessity” field, and an “update time” field. Registered in the “occurrence position” column is data including a set of element data in which an index word is generated and a logical object ID and slot ID for specifying object data having the element data. In the “deletion / insertion” column, information for determining whether the element data is scheduled to be deleted or inserted is registered. Here, for example, if “to delete” is scheduled, “insert” is registered if “delete” is to be inserted. The “necessity of confirmation” column indicates whether or not it is necessary to check whether the element data is actually stored in the object data storage unit 23 (valid or invalid) at the time of data reference (data search). Information (flag information) is registered. Here, for example, “necessary” is registered if it is necessary to check, and “no” is registered if not necessary. In the “update time” column, the time (update confirmation (commit) time) when the element data is updated is registered.

  In FIG. 3, a record (occurrence position data) “LOID5, SLOT0, Insertion, No, Time6” is registered in the occurrence position table associated with “memory” in the “vocabulary” column of the index data. This is because the word “memory” is generated in the slot (“0” slot) of the slot ID “SLOT0” of the object data having the logical object ID “LOID5”. The update time is “Time 6” and is committed. This means that slot check is not necessary when data is referred to.

  FIG. 4 shows an example of a map table stored in the map table storage unit 22. In the map table, a plurality of data, each of which is a set of a logical object ID (LOID) and a physical object ID (POID) of object data having the logical object ID and a physical object ID when committed, are registered. Is. For example, it means that the logical object ID “LOID5” is converted into the physical object ID “POID5”.

  When a data update request is input, the update processing unit 2 updates the index data and the object data. Until the data update is committed (update is confirmed), the reference process accepted from the start of the update until the update is confirmed can be controlled so that only the result before the update can be seen and the result after the update cannot be seen. There must be. For this reason, the information management apparatus 1 uses the version data table 12 to control the appearance of the update contents for the data reference process.

  The version data management unit 5 updates the index data in the version data table 12 and the index data storage unit 21 at the time when the reference process that only shows the state before the update of the object data storage unit 23 is completed, and the object data The storage area that is no longer needed in the storage unit 23 is released.

  When a commit request is input, the commit processing unit 3 regards that the data update has been confirmed, and updates the map table stored in the map table storage unit 22 and the index data stored in the index data storage unit 21. I do. In addition, it is necessary to show the result before the update for the reference processing executed by the reference processing unit 4 before and after the commit. For this purpose, the version data table 12 is updated.

  When a data reference request is input, the reference processing unit 4 performs access from the index data access to the object data or directly from the object data. As a data reference rule, it must be a reference to the object data storage unit 23 in the state when the data reference request is received. That is, even if there is a committed snapshot of the object data storage unit 23, data consistency will be lost unless the snapshot is referenced.

  The basic operation in the reference processing unit 4 when starting from access to index data is the generation position data of element data that satisfies the conditions from the index data (including numerical values, symbols, vocabulary, etc. specified as conditions). The set is taken out, the logical object ID is converted into the physical object ID in the map table stored in the map table storage unit 22, and the object data in the object data storage unit 23 is accessed. The basic operation for directly accessing the object data is to convert the logical object ID to the physical object ID in the map table and access the object data in the object data storage unit 23.

  Here, referring to FIG. 5, the search process (reference process Query3, Query4) started before the start of the update of object data (update process TXN2) and continued after the update is committed, and the update A case will be described in which search processing (reference processing Query2) started after committing is committed. That is, in such a case, the reference process Query 3 and Query 4 are switched with the object data before update as a reference target, and the reference process Query 2 is switched with the updated (update result) object data as a reference target.

  FIG. 5 shows the time of occurrence and end of each of the two update processes and the four reference processes in time series. FIG. 5 shows the following update process and reference process. In FIG. 5, the time updates such as “Time6” to “Time7” and “Time7” to “Time8” are updated because the update process not shown in FIG. 5 is committed. .

  An update process TXN1 occurred at time “Time6”, and object data (“memory”, “database”) of the logical object ID “LOID5” was stored.

  The reference process Query1 occurred at time “Time7”, the search (reference) process for object data including the vocabulary “memory” was started, and the search process was completed during the time “Time7”.

  The reference process Query3 occurs at time “Time7”, the search (reference) process for object data including the vocabulary “memory” and “semiconductor” is started, and the search process ends at the time “Time9”.

  The reference process Query4 occurs at time “Time7”, the search (reference) process for object data including the vocabulary “disc” is started, and the search process ends at time “Time9”.

  The update process TXN2 occurred at time “Time8”, and the “memory” of the object data of the logical object ID “LOID5” was updated to “disk”.

  The reference process Query2 occurs at time “Time9”, the search (reference) process for object data including the vocabulary “memory” is started, and the search process ends during the time “Time9”.

  In the state shown in FIG. 5, the reference target of each reference process is only the object data that has already been committed at the time when the reference request for the reference process occurs. For example, in the reference process Query 1, the update result of the update process TXN 1 is a reference target, and the object data (“memory”, “database”) of the logical object ID “LOID 5” can be referred to. In the reference process Query2, the update result in the update process TXN2 is a reference target, and the object data ("memory", "database") cannot be referred to. Instead, the update result (“disk”, “database”) in the update process TXN2 is a reference target.

  In the reference processes Query3 and Query4, the update target of the update process TXN1 that has already been committed before the occurrence of these reference requests is the reference target. However, since the update process TXN2 occurs during the reference process and the update is committed, the update result is not made the reference target of the reference process Query3 or Query4 after the update process TXN2 ends (after the commit). Need to control. That is, since the reference processing Query3 and Query4 should refer to the object data before the update processing TXN2 occurs, the object data before the update processing TXN2 is retained even after the update processing TXN2 is completed. Then, at least until the reference process Query3 or Query4 is completed, the reference process Query3 or Query4 is displayed with the object data before the update process TXN2 is updated, and the search process (for example, a reference request is made after the update process TXN2 is completed) In FIG. 5, the reference process Query2) is switched to show the updated object data of the update process TXN2.

  Next, the update processing operation of the information management apparatus 1 in FIG. 1 will be described with reference to the flowchart shown in FIG.

  Here, the update process operation of the update process TXN2 of FIG. 5 will be described as an example, and the states of the object data storage unit 23, the index data storage unit 21, and the map table storage unit 22 before the update are shown in FIG. Assume that the state is as shown in FIG.

  For example, an update request from the terminal TE1 to the object data (“memory”, “database”) of the logical object ID “LOID5”, and the update is performed by changing the first element data “memory” of the object data to “disk”. Suppose a request message is sent. This update corresponds to the update process TXN2 of FIG.

  The update request message is received by the update processing unit 2. First, the update processing unit 2 obtains the current time (update time) from the time management unit 6 (step S1). Here, the time is a number assigned serially after the information management apparatus 1 is activated, and increases by “1” by the commit process. In other words, it is assumed that the temporal relationship between the time when the update is confirmed (the time when the update is committed) and the time when the reference request is generated can be understood from the time.

  At the time when the update processing unit 2 receives the update request (time “Time 8”), as is apparent from FIG. 5, there are two reference requests generated at the time “Time 7” (Query 3 and Query 4). These reference processes are still ongoing. The reference log table 13 at time “Time 8” is shown in FIG. As illustrated in FIG. 7, the reference log table 13 registers the number of reference processes for which reference processes are currently being performed, for each occurrence time of the reference processes. For example, in FIG. 7, “2” is registered as the number of reference processes (Query3, Query4) that occurred at time “Time7”.

  Next, the update processing unit 2 stores a copy of the object data to be updated in an unused storage area in the object data storage unit 23. Then, the updated new element data is stored in an unused slot (step S2).

  For example, as shown in FIG. 9, the copy of the object data of the physical object ID “POID5” to be updated is stored in the physical object ID “POID21”, which is an empty area in the object data storage unit 23, and is stored in the first slot. “Disk” which is new element data replacing element data is stored in an empty slot (slot ID “SLOT2”).

  In this way, the object data before update is left as it is, and a copy of the object data before update is updated and stored as new object data in a storage area different from the object data before update. Then, the unused slot “SLOT2” is allocated for the new head element data “disk” without using the first slot “SLOT0” before the update, and the validity of the generated position data is as follows. , Can control the invalidity.

  (A) If the “necessity of confirmation” column of the occurrence position table is “necessary” and the slot represented by the occurrence position data does not actually exist in the object data storage unit 23, the occurrence position data is invalid. is there.

  (B) If the “necessity of confirmation” column of the generation position table is “necessary” and the slot represented by the generation position data actually exists in the object data storage unit 23, the generation position data is valid. .

  (C) If the “confirmation necessity” column of the occurrence position table is “No”, the occurrence position data is valid.

  It can be judged. Such a determination is made in a reference process described later.

  The update processing unit 2 updates the index data corresponding to the new element data added by the update as the object data in the object data storage unit 23 is updated, and the index corresponding to the element data deleted by the update. Data is updated (step S3). Specifically, an index word corresponding to the added new element data and the occurrence position data are added to the occurrence position table (addition of data to the index data in FIG. 3). At this time, the “delete insertion” field of the new generation position data added to the generation position table is “insertion”, the “necessity of confirmation” field is “necessary”, and the update time is registered in the “update time” field. Absent. Further, “necessary” is set to “necessary” in the “necessity of confirmation” column in the generation position data corresponding to the element data to be deleted.

  For example, here, since the element data “memory” is an update to be rewritten to “disk”, first, as shown in FIG. 10, it is generated in association with the vocabulary “disk” in the “vocabulary” column of the index data. New generation position data whose position is the logical object ID “LOID5” and the slot ID “SLOT0” is added to the generation position table. Further, since the element data “memory” is scheduled to be deleted, as shown in FIG. 10, “No” in the “necessity of confirmation” column in the generation position data corresponding to the element data is set to “necessary”.

  Next, the commit processing operation of the information management apparatus 1 in FIG. 1 will be described with reference to the flowchart shown in FIG. The commit process is a process for confirming the update contents by the update process. When the commit process ends, the update process ends. Here, a commit process for ending the update process TXN2 will be described as an example.

  As described above, the terminal TE1 transmits a commit request message for committing to the update in which the element data “memory” is rewritten to “disk” to the information management apparatus 1. The commit request message is received by the commit processing unit 3 (step S11).

  When the commit processing unit 3 accepts the commit request, as shown in FIG. 12, the update time (in this example, “Time 8”) of the update and the logical object ID of the object data to be updated (as shown in FIG. 12) Here, for example, “LOID5”), a new physical object ID in which the updated object data is stored (here, “POID21”, for example), and a physical object ID in which the object data before the update is stored (in this case, for example, "POID5") is registered (step S12).

  In the version data table 12, as shown in FIG. 12, at the time of committing the update, the update time that is the start time of the update, the logical object ID (LOID) of the update target object data, and the post-update A new physical object ID (NewPOID) in which object data is stored and a physical object ID (OldPOID) in which object data before update is stored are registered.

  For example, the version data table 12 shown in FIG. 12 indicates that the physical object ID of the object data with the logical object ID “LOID5” has been changed from “POID5” to “POID21” at the time “Time8”. Yes. In the reference process started before the time “Time8”, if the object ID of the logical object ID “LOID5” is to be referred to, the physical object ID “POID5” in the object data storage unit 23 is accessed. It will be good.

  The version data table 12 is sorted in descending order by the time in the “update time” column.

  Next, the commit processing unit 3 updates the “deletion / insertion” column and the “update time” column of the generated position data corresponding to the element data before the update stored in the index data storage unit 21 and after the update. The “update time” column of the generated position data corresponding to the element data is updated (step S13). Specifically, by updating, “delete” is registered in the “delete insertion” field of the occurrence position data corresponding to the element data to be deleted, and the time acquired by the update process is registered in the “update time” field. . In addition, the time acquired by the update process is registered in the “update time” column of the generated position data corresponding to the element data scheduled to be added (inserted) by update.

  For example, as shown in FIG. 13, when the element data “memory” of the object data of the logical object ID “LOID5” is rewritten to the element data “disk”, it corresponds to the element data “memory” before the update. Since the occurrence position data 101 to be deleted is scheduled to be deleted, “insert” in the “delete insertion” column is rewritten to “delete”, and the time “Time 8” acquired in the update process is registered in the “update time” column. In addition, the time “Time 8” acquired by the update process is registered in the “update time” column of the generated position data 102 corresponding to the updated element data “disk”.

  Next, the commit processing unit 3 updates the map table stored in the map table storage unit 22 (step S14). That is, in order to reflect the committed update result in the map table, as shown in FIG. 14, the physical object ID associated with the logical object ID of the object data to be updated is stored in the object data after update before update. The physical object ID is rewritten.

  In FIG. 14, the physical object ID corresponding to the logical object ID “LOID5” is rewritten from “POID5” to the physical object ID “POID21” in which the updated object data is stored.

  Further, the commit processing unit 3 stores in the update log table 11 the time (in this case, “Time8”) acquired at the beginning of the update processing and the physical object ID (in this case, “POID5”) of the object data to be updated. As shown in FIG. 8, it is registered in the update log table 11 (step S15). As shown in FIG. 8, the update log table 11 includes an update log that includes a set of the time (update time) when the update process occurs and the physical object ID of the object data that is the update target by the update process. be registered.

  Finally, the time is incremented by 1 (step S16). Here, “Time 8” is updated to “Time 9”.

  Next, the reference processing operation of the information management apparatus 1 in FIG. 1 will be described with reference to the flowcharts shown in FIGS. Here, the reference processing operation of the reference processing QUERY3 in FIG. 5 will be described as an example. In this case, as is clear from FIG. 5, there is no ongoing update process at the time when the reference request for the reference process QUERY 3 is received. All object data in the object data storage unit 23 is committed. Therefore, no record exists in the update log table 11. In addition, as shown in FIG. 18, the reference log table 13 records a reference log record corresponding to the reference process QUERY1 started at time “Time7”.

  In this state, a reference request message stating “take out object data including any one of“ memory ”and“ semiconductor ”” is transmitted from the terminal TE1 to the information management apparatus 1. The reference request message is received by the reference processing unit 4.

  When receiving the reference request message, the reference processing unit 4 first obtains the current time (reference time) Tq from the time management unit 6. Here, “Time 7” is obtained. As a result, the number of references corresponding to “Time7” in the reference log table 13 is increased by 1 and updated to “2” (step S21).

  Next, the reference processing unit 4 accesses the index data storage unit 21 and generates generated position data from the position generation table stored in association with “memory” and “semiconductor” in the “vocabulary” column in the index data. Is obtained (step S22). When collecting the occurrence position data here, the occurrence position data in which the update time is not described in the “update time” field but is blank (or “NULL”) may be excluded. This is because the occurrence position data in which the “update time” field is blank (or “NULL”) is the occurrence position data of element data that is being updated but not committed as described above. Further, when the “deletion / insertion” field is “insertion”, the time of the “update time” field is before the reference processing time Tq of the reference process, and when the “deletion / insertion” field is “deletion”, If the time is registered regardless of the time before or after the reference processing time Tq of the reference processing, the time may be collected.

  Hereinafter, (Case X1) when the reference processing unit 4 accesses the database 20 before all other transactions (for example, update processing TXN2 in this example) are started, and (Case X2) at least one other transaction (For example, update processing TXN2 in this example) has started, but when the commit is not committed, the reference processing unit 4 accesses the database 20, and (case X3) all transactions (update in this example) The case where the reference processing unit 4 accesses the database 20 after the processing TXN2) is completed will be described separately.

  (Case X1) When the reference processing unit 4 accesses the database 20 before all other transactions (for example, the update process TXN2 in this example) are started.

  The states of the object data storage unit 23, the index data storage unit 21, and the map table storage unit 22 are the states shown in FIGS. Therefore, in step S22, a set of generated position data including the generated position data 101 is obtained from the index data shown in FIG.

  The processing of step S24 to step S33 is repeated for each of the obtained generation position data (step S23 to step S34). That is, in step S24, the “confirmation necessity” column in the generated position data is checked. In the case of (Case X1), it can be expected that the “confirmation necessity” column of all the obtained occurrence position data is “No”, and thus the process proceeds to Step S31. In step S31, a logical object ID (LOID) is extracted from the generation position data currently being processed, and a physical object ID (POID) corresponding to the LOID is obtained from the map table. For example, when the generated position data to be processed is the generated position data 101, since the logical object ID is “LOID5”, the physical object ID “POID5” is obtained from the map table shown in FIG. In step S33, the object data is read from the storage area corresponding to the physical object ID “POID5” in the object data storage unit 23.

  The processes in steps S24 to S34 described above are performed for all occurrence position data obtained in step S22.

  Thereafter, the process proceeds to step S51 in FIG.

  (Case X2) When the reference processing unit 4 accesses the database 20 when at least one other transaction (for example, the update process TXN2 in this example) is started but not committed.

  The object data storage unit 23 is in the state shown in FIG. 9, the index data storage unit 21 is in the state shown in FIG. 10, and the map table storage unit 22 is in the state shown in FIG. Also in this case, in step S22, a set of generated position data including the generated position data 101 is obtained from the index data shown in FIG. For example, even if the generation position data is stored in association with “memory”, the generation position data whose “update time” field is blank (or “NULL”) is updated as described above. It is the generation position data of element data that is in the middle but not committed, and such generation position data may be excluded. The processing of step S24 to step S33 is repeated for each of the obtained generation position data (step S23 to step S34). That is, in step S24, the “confirmation necessity” column in the generated position data is checked. In the case (Case X2), the update process TXN2 has been started, but has not been committed yet. Accordingly, there is occurrence position data in which “required” is “necessary” in the “confirmation necessity” column. For example, since the generation position data 101 is currently being updated as is apparent from FIG. 10, the “necessity of confirmation” column is “necessary”. In this case, the process proceeds to step S61 in FIG.

  In step S61, the “deletion / insertion” column of the generation position data currently being processed is checked. When the “delete insertion” field is “delete”, the process proceeds to step S 62, the oldest reference time currently in the reference log table 13 is acquired, and the “update time” of the reference time and the generation position data to be processed is acquired. Compare with column update time. When the update time of the generated position data to be processed is earlier than the acquired reference time, the process proceeds to step S64, where the generated position data to be processed is deleted from the set of generated position data, and step S34 in FIG. Proceed to On the other hand, when the update time of the generation position data to be processed is after the acquired reference time, the process proceeds to step S65.

  If it is determined in step S61 that the “deletion / insertion” field of the occurrence position data currently being processed is “insertion”, the process proceeds to step S63, where the current oldest reference time is acquired in the reference log table 13, and the reference time And the update time in the “update time” column of the generation position data to be processed. When the update time of the generation position data to be processed is before the acquired reference time, the process proceeds to step S66, and the “confirmation necessity” column in the generation position data to be processed is changed from “required” to “not”. rewrite. Thereafter, the process proceeds to step S66 ′, the POID corresponding to the LOID of the generated position data is acquired from the map data, and the process proceeds to step S72, where the object data is stored in the object data storage unit 23 from the storage area corresponding to the obtained POID. Is read.

  On the other hand, when the update time of the generation position data to be processed is after the acquired reference time in step S63, the process proceeds to step S65.

  In step S65, the version data table 12 is referred to and it is checked whether or not there is a committed update for the logical object ID in the generation position data that is currently processed. If such a record (version data) exists, the process proceeds to step S67, and if not, the process proceeds to step S68.

  In step S67, the update time included in the version data is compared with the time (reference time) acquired at the start of the current reference process. If the update time of the version data is earlier than the reference time, the update result can be referred to, and the process proceeds to step S69. If the update time of the version data is later than the reference time, it is impossible to refer to the update result, and the process proceeds to step S70.

  In step S69, “NewPOID” is extracted from the version data. In step S70, “OldPOID” is extracted from the version data. Thereafter (because the “necessity of confirmation” column is “necessary”), the process proceeds to step S71, and the storage location in the object data storage unit 23 corresponding to the obtained POID is designated by the generation position data to be processed. It is confirmed whether there is a slot having the specified slot ID. If there is a slot with the slot ID, the process proceeds to step S72, and object data is read from the storage area corresponding to the obtained POID in the object data storage unit 23. In step S71, when there is no slot having the slot ID, object data is not read from the POID, and the process proceeds to step S34 in FIG. 15 to determine whether there is generation position data to be processed next. Check out.

  In step S68, the POID corresponding to the LOID in the generation position data to be processed is obtained from the map data, and the process proceeds to step S71.

  A version corresponding to the update process, which is started after the start time (reference time Time7) of the reference process QUERY3 currently being performed, and there is a committed update to the logical object ID in the generation position data currently being processed. If data exists, the process proceeds to step S70. Before the start time (reference time Time7) of the reference process QUERY3 currently being performed, there is a committed update to the logical object ID in the occurrence position data that is the current process target, and the version data corresponding to the update process If exists, the process proceeds to step S69.

  Processes other than those described above are the same as in (Case X1).

  (Case X3) When the reference processing unit 4 accesses the database 20 after completion of all transactions (in this example, the update process TXN2).

  The object data storage unit 23 is in the state shown in FIG. 9, the index data storage unit 21 is in the state shown in FIG. 13, and the map table storage unit 22 is in the state shown in FIG. Further, as shown in FIG. 12, the version data table 12 records a record 201 related to the update (update time “Time 8”) by the update process TXN2. In this case, in step S22, a set of generated position data including the generated position data 101 is obtained from the index data shown in FIG.

  The processing of step S24 to step S33 is repeated for each of the obtained generation position data (step S23 to step S34). That is, in step S24, the “confirmation necessity” column in the generated position data is checked. In the case of (Case X3), since the update process TXN2 is committed, there is occurrence position data in which the “necessity of confirmation” column is “necessary”. For example, as is apparent from FIG. 13, the occurrence position data 101 is “necessary” in the “confirmation necessity” column. In this case, the process proceeds to step S61 in FIG.

  In step S61, since the “deletion / insertion” field of the generated position data 101 is “cut”, the process proceeds to step S62. Since the reference processing QUERY3 and QUERY4 started before the update time “Time8” of the occurrence position data 101 exists, the process proceeds from step S62 to step S65. Referring to the version data table 12, the version data table 12 includes a version of the update time “Time8” of the update process TXN2 that has been started after the start time (reference time Time7) of the reference process QUERY3 that is currently being performed. Data 201 exists. The update target of the update process is the object data with the logical object ID “LOID5”.

  The logical object ID included in the generation position data 101 to be processed is “LOID5” and the slot ID “SLOT0”. Since the version data 201 exists in the version data table 12 and the update time “Time8” in the version data is after the start time (reference time Time7) of the reference processing QUERY3 currently performed, the steps from step S67 are performed. Proceed to S70. In step S <b> 70, OldPOID “POID5” is extracted from the record 201 of the version data table 12. Then, the process proceeds to step S71, and it is checked whether or not a slot with the slot ID “SLOT0” exists in the storage area corresponding to the physical object ID “POID5” in the object data storage unit 23. In this case, since the slot exists, the process proceeds to step S72, and the object data is read from the storage area. Thereafter, the process proceeds to step S34 in FIG.

  Processing other than the above is the same as in (Case X1).

  In each case of (Case X1) to (Case X3), by executing the processing of Step S24 to Step S34 described above, object data as a reference result is obtained from the set of generation position data obtained in Step S22. Since it is obtained, the process proceeds to step S51 in FIG. 17, and the reference processing unit 4 decreases the number of references of the reference time “Time7” in the reference log table 13 by one.

  At this time, when the reference number of the reference time “Time7” becomes “0”, the process proceeds to step S53, and when the reference number is “1” or more, the process ends. The processing after step S53 is performed by the version data management unit 5.

  In step S53, the record with the reference number “0” is deleted from the reference log table 13. Thereafter, the oldest reference time in the reference log table 13 is acquired, and the reference time is compared with the update time in the update log table 11. If there is a record with an update time earlier than the reference time in the update log table 11, the process proceeds to step S55, and if not, the process ends.

  For example, from FIG. 5, when the reference number of the reference time “Time7” becomes “0” (time “Time9”), that is, when the reference processing QUERY3 and QUERY4 are completed, the oldest reference in the reference log table 11 The time is “Time9”. At this time, the update log table 11 is in the state shown in FIG. In this case, in step S54, an update log at the update time “Time8” is detected. In step S55, the version data 201 at the update time “Time8” is deleted from the version data table 12 in FIG. 12, and the update log at the update time “Time8” is deleted from the update log table 11.

  Next, in step S56, the version data management unit 5 releases the storage area in the object data storage unit 23 corresponding to “OldPOID” in the version data deleted in step S55 (set as an empty storage area). . For example, when the version data 201 of the update time “Time8” in FIG. 12 is deleted in step S55, “OldPOID” is “POID5”, and therefore in step S56, “POID5” in the object data storage unit 23 is set. The corresponding storage area is released, and the storage area corresponding to “POID5” becomes a free storage area. In FIG. 17, the update log data and version data that are no longer necessary are deleted (step S55), and the storage area of the object data storage unit 23 is released (step S56). After performing S56, the process of step S55 may be performed.

  Next, referring to the flowcharts shown in FIGS. 15 to 17, the reference processing operation of the information management apparatus 1 in FIG. 1 will be described with reference to the reference processing operation in the reference process QUERY 4 in FIG. 5 as an example. Here, a description will be given of parts different from the reference processing operation of the reference processing QUERY3 of FIG. The reference process QUERY 4 is a reference process for extracting object data including “disk”. As illustrated in FIG. 5, the reference process QUERY 4 is started at the same time as the reference process QUERY 3 and is committed and ended at the same time.

  As is clear from FIG. 5, as in the case of the reference process QUERY3 described above, there is no ongoing update process when a reference request for the reference process QUERY4 is received. All object data in the object data storage unit 23 is committed. In addition, there is no record in the update log table 11. In the reference log table 13, as shown in FIG. 18, a record of the reference log corresponding to the reference process QUERY1 started at time “Time7” is recorded.

  In step S21 of FIG. 15, when the reference processing message transmitted from the terminal TE1 and indicating that “object data including“ disk ”is extracted” is received by the reference processing unit 4 of the information management device 1, the reference processing unit 4 The index data storage unit 21 is accessed, and a set of generated position data is obtained from the generated position table stored in association with “disk” in the “vocabulary” column in the index data (step S22).

  When the reference processing unit 4 accesses the database 20 before starting the update process TXN2 (Case X1), it is the same as the case of the reference process QUERY3 described above. If the reference processing unit 4 accesses the database 20 when the update process TXN2 is started but not committed (case X2), in step S22, the generated position data in the index data shown in FIG. 102 is ignored. This is because the “update time” column is blank (or “NULL”).

  When the reference processing unit 4 accesses the database 20 after the update by the update process TXN2 is committed (case X3), the generation position data 102 in the index data shown in FIG. 13 is obtained in step S22. Since the “confirmation necessity” column of the occurrence position data 102 is “necessary” and the “delete insertion” column is “insertion”, the process proceeds to step S61 and step S63 in FIG. The “update time” of the occurrence position data 102 is “Time8”, and update processing QUERY3 and QUERY4 started before this exist, so the process proceeds to step S65, and the logical object ID “LOID5” in the occurrence position data 102 is present. Version data 201 for is acquired, and the process proceeds to step S67. In step S67, the update time “Time8” included in the version data is later than the time acquired at the start of the current reference process (reference time “Time7”). Remove “OldPOID” from The subsequent processing is the same as described above.

  Next, the reference processing operation of the information management apparatus 1 in FIG. 1 will be described with reference to the flowcharts shown in FIGS. 15 to 17 by taking the reference processing operation of the reference processing QUERY2 in FIG. 5 as an example. Here, a description will be given of parts different from the reference processing operation of the reference processing QUERY3 of FIG. The reference process QUERY2 is a reference process for extracting object data including “memory”. As illustrated in FIG. 5, the reference process QUERY2 starts at time “Time9” after the update process TXN2 ends (after commit). At the start of the reference process QUERY2, the reference processes QUERY3 and 4 are also being processed.

  After the update by the update process TXN2 is committed, the object data storage unit 23 is in the state shown in FIG. 9, the index data storage unit 21 is in the state shown in FIG. 13, and the state of the map table storage unit 22 is This is the state shown in FIG. Further, as shown in FIG. 12, the version data table 12 records a record 201 related to the update (update time “Time 8”) by the update process TXN2. In this case, in step S22, a set of generated position data including the generated position data 101 is obtained from the index data shown in FIG.

  The processing of step S24 to step S33 is repeated for each of the obtained generation position data (step S23 to step S34). That is, in step S24, the “confirmation necessity” column in the generated position data is checked. As is clear from FIG. 13, the occurrence position data 101 is “necessary” in the “necessity of confirmation” column. In this case, the process proceeds to step S61 in FIG.

  In step S25, since the “deletion / insertion” field of the generated position data 101 is “cut”, the process proceeds to step S62. Since the reference process started before the update time in the “update time” column of the generation position data 101 to be processed is still continuing, the process proceeds to step S65.

  Version data 201 corresponding to the logical object ID “LOID5” included in the generation position data 101 that is currently processed exists in the version data table 12, and the update time “Time8” of the version data 201 is from the reference time “Time9”. Since it is before, it progresses to step S67, S69. In step S69, NewPOID “POID21” is extracted from the record 201 of the version data table 12. Then, the process proceeds to step S71, and whether there is a slot having the slot ID “SLOT0” specified in the generation position data 101 to be processed in the storage area in the object data storage unit 23 corresponding to the obtained POID. Check. In this case, as shown in FIG. 9, the storage area of “POID21” has no slot with the slot ID “SLOT0” (since the update to delete “memory” has been committed), so the process proceeds to step S34 in FIG. move on.

  The above update and reference processing is summarized as follows.

  In the update process of object data, first, the update start time (update time) is acquired. A copy of the object data to be updated is stored in a storage area different from the storage area of the object data to be updated, and is updated on the storage area of the copy. After the update is confirmed (after commit), the update time, the LOID (logical object ID) of the object data to be updated, the POID (physical object ID) indicating the address of the storage area of the object data before the update, and the post-update Version data is stored as a set of POIDs representing addresses of storage areas of the object data.

  When the object data to be updated is the reference target of the reference process (first reference process) that is started before the start of the update process and continues even after the end of the update process (after commit), the first reference The process shows the state before update, and when it becomes the reference target of the reference process (second reference process) started after the end of the update process, the object data that was the update target is switched so that the state after the update is shown Therefore, the version data is referred to.

  The index data includes index words such as vocabulary, numerical values, symbols, etc., element data including the index words, and generation position data for specifying object data having the element data (the generation position of the index word is LOID and slot ID) ). The generation position data of the element data added (including new addition) or deleted by the update process of the object data includes the update time of the update process. When the generated position data is accessed in the first reference process and the second reference process, the POID of the object data before update is provided to the first reference process, and the second reference process is used for the second reference process. Refers to the above version data for providing the POID of the updated object data. As a result, the slot containing the desired vocabulary is included in the object data before update, and the object data after update May not be included, or vice versa. Accordingly, flag information for instructing whether or not there is a slot having the slot ID specified by the generated position data in the storage area corresponding to the obtained POID so that object data including a desired vocabulary is always obtained. (Information in the “necessity of confirmation” column) is included in the occurrence position data.

  In the reference process, first, the time (reference time) at the start of the reference process is acquired. With reference to the index data, a set of generation position data of element data including a desired vocabulary is obtained. For each occurrence position data obtained, when the update time included in the occurrence position data is later than the reference time or “NUll”, a POID storing object data before update is provided, and the occurrence position data is included in the occurrence position data. When the included update time is before the reference time, a POID in which the updated object data is stored is provided.

  For occurrence position data in which “necessary” is recorded in the “necessity of confirmation” column of the obtained occurrence position data, the slot of the slot ID specified by the occurrence position data is stored in the storage area corresponding to the obtained POID. Is actually present, and if it exists, the object data is read from the storage area of the POID.

  As a result, since the reference process Query2 in FIG. 5 is a reference process started after the update in the update process TXN2 is committed, the object data of the physical object ID “POID5” before the logical object ID “LOID5” is updated. ("Memory", "Database") cannot be referenced. Also, in the reference processing Query3 and Query4, the update result of the update processing TXN1 that has already been committed before the occurrence of these reference requests becomes the reference target, and the update of the update processing TXN2 that has occurred and committed during these reference processing is updated. Results are not subject to reference.

  As described above, in the above-described embodiment, not only the reference process started before the start of the update process, but also the reference process that continues even after the end of the update process (after the commit) (first reference process). For example, the state before update is provided and the state after update is provided for the reference process (second reference process) started after the end of the update process. Can be easily performed. In other words, even if the database is updated during the reference process, the state in the database at the time of the reference request can be maintained for the reference process.

The figure which showed the structural example of the information management apparatus which concerns on embodiment of this invention. The figure which showed typically the example of a memory | storage of the object data in an object data storage part. The figure which showed typically the memory | storage example of the index data memorize | stored in an index data memory | storage part. The figure which showed an example of the map table memorize | stored in the map table memory | storage part. The figure for demonstrating simultaneous execution control of an update process and a reference process. The flowchart for demonstrating update process operation | movement. The figure which showed an example of the reference log table. The figure which showed an example of the update log table. The figure which showed the mode of the object data storage part after an update. The figure which showed the mode of the index data storage part after an update. 10 is a flowchart for explaining a commit processing operation. The figure which showed an example of the version data table. The figure which showed the mode of the index data memory | storage part after a commit. The figure which showed the map table after a commit. The flowchart for demonstrating reference processing operation | movement. The flowchart for demonstrating reference processing operation | movement. The flowchart for demonstrating reference processing operation | movement. The figure which showed the reference log table at the time of receiving the reference request of reference processing QUERY3.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Information management apparatus, 2 ... Update processing part, 3 ... Commit processing part, 4 ... Reference processing part, 5 ... Version data management part, 6 ... Time management part, 10 ... Table storage part, 11 ... Update log table, 12 ... version data table, 13 ... reference log table, 20 ... database, 21 ... index data storage unit, 22 ... map table storage unit, 23 ... object data storage unit, TE1, TE2 ... terminal.

Claims (10)

A storage area in which object data before update is stored for a plurality of object data each including a plurality of element data and given an identifier, and object data to be updated among the plurality of object data A first storage means for storing the object data being updated or committed in a storage area different from the storage area;
Time management means for storing and updating a time incremented by “1” each time an update of one object data is committed;
(X) a plurality of index words, (y) an identifier of object data corresponding to each index word and having element data including the index word, and occurrence position information of element data including the index word in the object data If, when the element data becomes updated, becomes "necessary" to indicate that the element data in the storage area is necessary to examine whether the stored corresponding to the generated position information, to the occurrence position information When it is not necessary to check whether or not the corresponding element data is stored in the corresponding storage area, the confirmation necessity information that is “No” and whether the element data including the index word is “to be deleted” or “to be inserted” Information indicating whether or not the element data containing the index word is being updated, indicating that it is being updated, and when the update is committed, Second storage means for storing the generated position data including the update time is serial time,
For object data that has been committed to update, the identifier, the update time, the ID of the storage area that stores the object data before the update, and the ID of the storage area that stores the committed object data Third storage means for storing version data including:
For each object data, a fourth storage means for storing a map table including an identifier thereof and an ID of a storage area in which the latest object data among the committed object data is stored;
Means for accepting search requests;
From the second storage means, select a set of occurrence position data corresponding to the index word specified in the search request,
(A) In the set of generated position data, the confirmation necessity information is “necessary” and “to be deleted”, and the update time is the time when the search request is accepted For the occurrence position data after the time, the ID of the storage area of the object data before update corresponding to the identifier in the occurrence position data is acquired from the version data,
(B) For the occurrence position data in which the confirmation necessity information is “necessary” and “scheduled to be inserted” and the update time is before the reference time in the set of occurrence position data, the map search means for obtaining the ID of the storage area of committed object data to retrieve the ID of the storage area, or from the version data corresponding to the identifier corresponding from the table to the identifier in the generated position data,
A concurrent execution control device comprising:   The search means, for the occurrence position data whose confirmation necessity information is “No” in the set of occurrence position data, from the map table, in the storage area corresponding to the identifier in the occurrence position data. The simultaneous execution control apparatus according to claim 1, wherein the ID is acquired. The search means includes
For the occurrence position data that is “scheduled to be inserted” and the confirmation necessity information is “necessary” in the set of occurrence position data, a search request received before the update time in the occurrence position data is The simultaneous confirmation according to claim 1, wherein if there is not, the confirmation necessity information in the generated position data is updated to "No", and the ID of the storage area corresponding to the identifier in the generated position data is acquired from the map table. Execution control device. Fifth storage means for storing an update log including the update time of the object data to which the update is committed;
When there is no search request accepted before the update time in the update log, it corresponds to the update log, the version data including the update time, and the ID of the storage area before the update in the version data Deleting means for emptying the storage area in the first storage means;
The concurrency control device according to claim 1, further comprising: A storage area in which object data before update is stored for a plurality of object data each including a plurality of element data and given an identifier, and object data to be updated among the plurality of object data A first storage means for storing the object data being updated or committed in a storage area different from the storage area;
Time management means for storing and updating a time incremented by “1” each time an update of one object data is committed;
(X) a plurality of index words, (y) an identifier of object data corresponding to each index word and having element data including the index word, and occurrence position information of element data including the index word in the object data If, when the element data becomes updated, becomes "necessary" to indicate that the element data in the storage area is necessary to examine whether the stored corresponding to the generated position information, to the occurrence position information When it is not necessary to check whether or not the corresponding element data is stored in the corresponding storage area, whether the element data including the index word is “to be deleted” or “to be inserted”. Information indicating whether or not the element data containing the index word is being updated , indicating that it is being updated, and when the update is committed, before the start of the update Second storage means for storing generated position data including an update time that is a recording time;
For object data that has been committed to update, the identifier, the update time, the ID of the storage area that stores the object data before update, and the storage area that stores the object data after update Third storage means for storing version data including an ID;
For each object data, a fourth storage means for storing a map table including an identifier thereof and an ID of a storage area in which the latest object data among the committed object data is stored;
Search means;
A concurrent execution control method in a concurrent execution control device comprising:
The search means accepting a search request;
The search means selecting a set of occurrence position data corresponding to the index word specified in the search request from the second storage means;
Of the set of occurrence position data, the confirmation necessity information is “necessary” and “scheduled to be deleted”, and the update time is after the reference time which is the time when the search request is received. For the generated position data, the search means acquires from the version data the ID of the storage area of the object data before update corresponding to the identifier in the generated position data;
Of the set of occurrence position data, for the occurrence position data whose confirmation necessity information is “necessary” and “scheduled to be inserted” and whose update time is before the reference time, the search means includes: obtain the ID of the storage area corresponding to the identifier of the generation position in the data from said map table, or acquiring the ID of the storage area of the object data after updating corresponding to the identifier from the version data,
A concurrent execution control method comprising:   For the occurrence position data in which the confirmation necessity information is “No” in the set of occurrence position data, the search means stores, from the map table, the storage area corresponding to the identifier in the occurrence position data. 6. The simultaneous execution control method according to claim 5, further comprising a step of acquiring an ID. A storage area in which object data before update is stored for a plurality of object data each including a plurality of element data and given an identifier, and object data to be updated among the plurality of object data A first storage means for storing the object data during update or after update commit in a storage area different from
Time management means for storing and updating a time incremented by “1” each time an update of one object data is committed;
(X) a plurality of index words, (y) an identifier of object data corresponding to each index word and having element data including the index word, and occurrence position information of element data including the index word in the object data And flag information indicating whether or not the element data including the index word is valid, and, in the case of valid element data that has been updated , the update time that is the time when the update is started Second storage means for storing the generated position data;
For the object data that has been updated , the identifier, the update time, the ID of the storage area that stores the object data before the update, and the ID of the storage area that stores the object data that has been updated Third storage means for storing version data including
For each object data, a fourth storage means for storing a map table including an identifier thereof and an ID of a storage area in which the latest object data is stored among update commits;
Means for accepting search requests;
(A) A set of generated position data corresponding to the index word specified in the search request is selected from the second storage means, and (B) the flag information is valid among the set of generated position data. For the generated position data shown, the ID of the storage area corresponding to the identifier in the generated position data is obtained from the map table , and (C) the flag information is not valid in the set of generated position data. Is generated based on a comparison result between the update time in the version data corresponding to the identifier in the generated position data and a reference time that is the time when the search request is received . , the version storing area of ID and the update committed object data storage area of the object data before the update in data Either one of the ID, and searching means for acquiring the ID of the storage area corresponding to the identifier in the generated position data,
A concurrent execution control device comprising: The occurrence position data corresponding to each index word further includes information indicating whether the element data including the index word is “to be deleted” or “to be inserted”,
The search means includes (c1) “occurrence of deletion” among occurrence position data indicating that the flag information is not valid, and the version data for occurrence position data whose update time is after the reference time. ID of the storage area of the object data before the update in (c2) “update schedule” and the update commit in the version data for the occurrence position data whose update time is before the reference time 8. The simultaneous execution control device according to claim 7, wherein the ID of the storage area of the completed object data is acquired. A storage area in which object data before update is stored for a plurality of object data each including a plurality of element data and given an identifier, and object data to be updated among the plurality of object data A first storage means for storing the object data during update or after update commit in a storage area different from
Time management means for storing and updating a time incremented by “1” each time an update of one object data is committed;
(X) a plurality of index words, (y) an identifier of object data corresponding to each index word and having element data including the index word, and occurrence position information of element data including the index word in the object data And flag information indicating whether or not the element data including the index word is valid, and, in the case of valid element data that has been updated , the update time that is the time when the update is started Second storage means for storing the generated position data;
For the object data that has been updated , the identifier, the update time, the ID of the storage area that stores the object data before the update, and the ID of the storage area that stores the object data that has been updated Third storage means for storing version data including
For each object data, a fourth storage means for storing a map table including its identifier and an ID of a storage area in which update commit has been completed and the latest object data is stored;
Search means;
A concurrent execution control method in a concurrent execution control device comprising:
The search means accepting a search request;
A selection step in which the search means selects a set of occurrence position data corresponding to the index word specified in the search request from the second storage means;
For the generated position data indicating that the flag information is valid in the set of generated position data, the search unit obtains the ID of the storage area corresponding to the identifier in the generated position data from the map table. A first acquisition step;
For the generated position data indicating that the flag information is not valid in the set of generated position data, the search means includes the update time in the version data corresponding to the identifier in the generated position data. , Based on the comparison result with the reference time that is the time when the search request is received, the ID of the storage area of the object data before the update in the version data and the ID of the storage area of the object data for which the update has been committed A second acquisition step of acquiring any one of and as an ID of a storage area corresponding to the identifier in the generated position data;
Concurrent execution control method. The occurrence position data corresponding to each index word further includes information indicating whether the element data including the index word is “to be deleted” or “to be inserted”,
In the second acquisition step, out of occurrence position data indicating that the flag information is not valid, (c1) “deletion schedule” and occurrence position data whose update time is after the reference time The ID of the storage area of the object data before update in the version data is acquired, (c2) For occurrence position data that is “to be inserted” and whose update time is before the reference time , concurrency control method according to claim 9, wherein the acquiring the ID of the storage area of the object data already the update committed.

Images