JP2513160B2 - Multi-version parallel control method and multi-version parallel control method in object-oriented database - Google Patents

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a multiversion parallel control method and a multiversion parallel control method in an object-oriented database in which the number of versions is limited.

[0002]

2. Description of the Related Art Conventionally, multi-version concurrency control has been proposed in order to prevent collision of long-running transactions in an object-oriented database (PABernst
ein, V. Hadzilacos and N. Goodman, “Concurrency Cont
rol and Recovery in DatabaseSystem. ”pages 143-16
6, Addison Wesley, 1987.). In this method, while accessing an object that has a read-only transaction (a transaction that only involves reading the database), an update transaction (a transaction that involves updating the contents of the database) tried to update that transaction. In this case, a copy of the object is created as a version, the update transaction updates the copy, and the read-only transaction accesses the original object to prevent collision of the two processes. However, this method can prevent the waiting state of the update transaction due to the read-only transaction, but the storage capacity is squeezed because the versions that cannot be removed are generated indefinitely until the access of the read-only transaction is completed. In the worst case, a read-only transaction is aborted (also known as rollback, the operation performed in the transaction is invalidated and terminated). FIG. 6 is an explanatory view of this conventional method, in which a transaction accessing a set of versions (a4, b5, c5, d5) and a set of versions (a3, b2, c2, d2) are accessed. There are two transactions in progress. here,
These sets of versions cannot be erased until the transaction that accesses them ends. In reality, the large number of such non-erasable versions results in the abort described above.

On the other hand, in recent years, in order to solve such a problem, a method of limiting the number of versions to be generated has been proposed (Kun-Lung Wu, Philip S. Yu and Ming-S).
yanChen, “Dynamic Finite Versioning: An Effective
Versioning Approach to Concurrent Transaction and
Query Processing. ”, ICDE, 1993.) This method defines the concept of snapshots.
A snapshot is a set of latest versions of a database viewed at a certain time. When the number of versions in the snapshot exceeds a certain number, a new version is not allocated to the read-only transaction, and the version corresponding to the latest version of the existing snapshot is read. FIG. 5 is an explanatory diagram for explaining the concept of snapshots. (A4, b4,
Even if a read-only transaction comes when the set of versions of c4, d4) is the latest, the version (a3, b2, c2, d2) corresponding to the latest snapshot is obtained.
) Read. This can limit the number of versions accessed by a read-only transaction that cannot be removed until the read is complete. However, a read-only transaction will read the version that was created a while ago rather than the latest version.

[0004]

Although the above-mentioned conventional snapshot method achieves the object of saving the storage capacity, it causes a problem that a read-only transaction must access a version a little before.

It is an object of the present invention to provide a method of accessing newer versions as much as possible while retaining the requirement of version restrictions.

[0006]

According to a first aspect of the present invention, in a multi-version parallel control method for an object-oriented database, a version belonging to a set X of versions accessed by a read-only transaction and a version Y belonging to a version Y committed by an update transaction are used. Regarding objects in which the same objects exist and the versions belonging to the version set X and the version set Y are not the same, the version generated next to the version belonging to the version set X is the version set. The barge to be read by the read-only transaction for objects that belong to Y and are not the same for the version set X and the version version Y belonging to the version set Y. If you do not have access to the version of the set X of emission is characterized by causing a transition to the set Y of the version that newly committed the set X of the version of the read-only transactions access.

A second aspect of the present invention is a multi-version concurrency control method for an object-oriented database, which includes a commit list which is a list of transactions that each transaction has and has already been committed when the transaction is started, and a current commit list. A commit list comparison unit that compares the global commit list, which is a list of all transactions committed up to, and outputs the first transition instruction if the elements are the same,
If the number of objects to be committed by the update transaction is less than or equal to the total number of objects existing in the database, an update object number checking unit that outputs a second transition instruction, and a version list management unit that manages a list of versions corresponding to the objects And a read list management unit that manages a list of read-only transaction identifiers that each version has accessed to the version, and one version before the version of the object that is committed by the update transaction via the version list management unit. Identification of the read-only transaction that takes out the generated version X and uses the read list management unit to access a set of versions including the version X to the elements of the list of the version X The identifier Y examine whether there is a Y
A read list comparison unit that outputs a third transition instruction when there is no such information, and a version accessed by the read-only transaction when the first transition instruction, the second transition instruction, and the third transition instruction are received. It is characterized in that it is composed of a set transition unit of a version that transitions the set of to the set of newly committed versions.

[Operation] Regarding a transaction committed after the start of the read-only transaction (committing the update operation performed in the transaction and writing to the database and terminating),
There is an object having the same version belonging to the set X of versions accessed by the read-only transaction and the set Y of versions committed by the update transaction, and the set X of versions is the same as the versions belonging to the set Y of versions. For the object which is not, the version generated next to the version belonging to the version set X is a version belonging to the version set Y, and the version set X and the version belonging to the version set Y are the same. If the read-only transaction does not access a version of the set X of versions to be read for an object that is not, then the set of versions accessed by the read-only transaction Wherein are transitioning to the version of the set Y to a new commit X. This allows a read-only transaction to read a newer version while maintaining the snapshot principle.

[0009]

Next, the present invention will be described with reference to the drawings.

FIG. 1 is a block diagram showing an embodiment of the present invention.

In this embodiment, as shown in FIG. 1, each transaction has a commit list (a list of transactions that have already been committed when the transaction is started) and a global commit list (commits up to now). A list of committed transactions), a commit list comparing section 1 for comparing the total number of objects existing in the database and the number of objects to be committed by the update transaction, and a version corresponding to the object. The version list management unit 3 that manages the list, the read list management unit 4 that manages the list of the identifiers of the read-only transactions that have accessed each version, and the version list management unit 3 The identifier of a read-only transaction that fetches the version X generated immediately before the version of the object to be committed by the transaction and accesses the set of versions including the version X to the elements of the list of the version X via the read list management unit 4. A version accessed by a read-only transaction when a predetermined condition is given by the read list comparing unit 5 for checking whether or not there is Y, the commit list comparing unit 1, the update object number checking unit 2, and the read list comparing unit 5. And the set transition unit 6 of the version that transits to the set of newly committed versions.

FIG. 2 is a flow chart for explaining the operation of this embodiment, and FIGS. 3, 4 and 5 are explanatory views of this embodiment.

In the following, Tr is the read-only transaction and VS is the set of versions accessed by Tr.
r, an update transaction is Tu, and a set of versions committed by Tu is VSu. Further, it is assumed that Tu commits after the time when Tr is started.

The commit list comparison unit 1 inputs Tr 1
1 and checks whether the commit list is the same as the global commit list (step 10
0), and outputs the result to the version set transition unit 6. That is, the commit list and the global commit list are compared, and if the elements are the same, it means that there is no transaction committed from the start of processing by Tr to the present. In other words, the version (b3, between VSr and VSu as shown in FIG.
c3, d3) does not exist. Thereby, V
It can be seen whether Sr is a set of versions committed one before VSu.

The update object number comparison unit 2 receives as input 12 the number of objects to be committed by Tu, checks that it is less than or equal to the total number of objects in the database (step 101), and transfers the result to the version set transition. Output to the unit 6. As described above, the absence of a version between VSr and VSu means that, as shown in FIGS. 4 and 5, the versions belonging to the set of two versions are not the same for all objects, or some of them are the same. Can be said to be. Further, if the number of objects to be committed by Tu in step 101 is less than or equal to the total number of objects in the database, the newly created version is a part, and the objects having the same corresponding versions in VSr and VSu are Exists and VS
It can be seen that for objects whose versions corresponding to r and VSu are not the same, the version generated next to the version belonging to VSr is the version belonging to VSu. That is, it can be seen that the state is as shown in FIG.

Next, the objects updated by Tu and committed are fetched one by one (step 102). The version list management unit 3 inputs the object 1
3, the version immediately before that version in the version list, that is, the version generated immediately before is fetched (step 104) and output. The read list comparing unit 5 receives the output of the version list managing unit 3 and the Tr identifier, and the Tr identifier is added to the list of the read-only transaction identifiers accessed by the version using the read list managing unit 4. Check for existence (step 10
5) The result is output to the version set transition unit 6. For example, referring to FIG. 5, the list of identifiers of read-only transactions that accessed the previous version (b2, c3, d3) of the object (b3, c3, d3) updated and committed by Tu is set to Tr. By checking whether the identifier exists, Tr is a portion where VSr and VSu do not overlap (b2, c2, d).
2) You can see if you are not accessing the version. That is, if the Tr identifier does not exist, Tr is VS.
Parts where r and VSu do not overlap (b2, c2, d2)
You can say that you are not accessing the version of.

The version set transition unit 6 does not transition the version set if any of the above-mentioned conditions received as an input is not satisfied. In other words, there is no version (b3, c3, d3) between VSr and VSu as shown in FIG. 3, and FIG.
As shown in, VSr and VSu overlap, and
There is no version updated and committed by another transaction between the non-overlapping parts, and further, as shown in FIG. 5, the previous version (b2) of the object (b3, c3, d3) updated and committed by Tu. ，
Only when the identifier of Tr does not exist in the list of the identifiers of read-only transactions that have accessed it in (c2, d2), the transition of the set of versions is performed. That is, even if the VSr is converted into the VSu, the read consistency of the Tr is maintained, so that the VSr is changed to the VSu (step 106).

[0018]

As described above, the present invention has the effect that a read-only transaction can read a newer version while maintaining the snapshot principle.

[Brief description of drawings]

FIG. 1 is a block diagram showing one embodiment of the present invention.

FIG. 2 is a flow chart showing the flow of processing of this embodiment.

FIG. 3 is a first explanatory diagram of the present embodiment.

FIG. 4 is a second explanatory diagram of the present embodiment.

FIG. 5 is a third explanatory diagram of the present embodiment.

FIG. 6 is an explanatory diagram of a conventional example.

FIG. 7 is an explanatory diagram of a conventional snapshot method.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 Commit list comparison unit 2 Update object number inspection unit 3 Version list management unit 4 Read list management unit 5 Read list comparison unit 6 Version set transition unit 11 Tr 12 Number of objects committed by Tu 13 Object updated by 13 Tu and committed

Claims (2)

(57) [Claims] 1. In a multi-version parallel control method for an object-oriented database, there is an object in which a version belonging to a set X of versions accessed by a read-only transaction and a set Y of versions committed by an update transaction are the same, and Regarding an object whose version set X and said version belonging to the version set Y are not the same, the version generated next to the version belonging to the version set X is a version belonging to the version set Y, and The set of versions X to be read by the read-only transaction for objects whose versions are not the same belonging to the set of versions X and the set of versions Y
, The set of versions Y accessed by the read-only transaction is newly committed.
A multi-version concurrency control method for object-oriented databases, characterized in that the transition is performed. 2. In a multi-version concurrent control method in an object-oriented database, a commit list that is a list of transactions that each transaction has and that has already been committed when the transaction is started, and all commits up to now The global commit list, which is a list of transactions, is compared, and if the elements are the same, the commit list comparison unit that outputs the first transition instruction and the number of objects to be committed by the update transaction of the objects that exist in the database If the total number is less than or equal to the total number, an update object number inspection unit that outputs a second transition instruction, a version list management unit that manages a list of versions corresponding to the objects, and individual versions have access to the versions And a read-list management unit that manages a list of identifiers of read-only transactions, and a read-list management unit that extracts the version X generated immediately before the version of the object to be committed by the update transaction via the version-list management unit. Section to check whether the element of the list held by the version X has the identifier Y of the read-only transaction that accesses the set of versions including the version X, and outputs the third transition instruction when the identifier Y does not exist. And a read list comparison unit for
Of the version transition instruction, the second transition instruction, and the third transition instruction, the read-only transaction transits the set of versions to a newly committed version set. A multi-version concurrency control method for object-oriented databases.