JPH05225034A - Object management method for object-oriented data base system - Google Patents

Abstract

PURPOSE:To provide the object management method for the object-oriented data base system which can effectively use a storage area. CONSTITUTION:A first table where identifiers 21A of permanent objects and position information 21B on a secondary storage area of permanent objects correspond to each other is stored in the secondary storage area 20. A second table where identifiers 31A, position information 31B on the secondary storage area, and position information 31C on a primary storage area of permanent objects correspond to one another is stored in the primary storage area 30. An object-oriented data base management system 10 accesses and manages permanent objects based on first and second tables.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an object management method in an object oriented database system.

[0002]

2. Description of the Related Art In recent years, an object oriented database system (Object Oriented Database = OODB) has attracted attention and various researches have been conducted.

The basic concept of an object-oriented database is as follows: (1) "" Basic concept of an object-oriented database "(Katsumi Tanaka, Information Processing Vol.32 No.5 pp500
~ 513 May 1991) "(hereinafter referred to as Reference 1), (2)
“Architecture of object-oriented database management system” (Kenfumi Makinouchi, Information Processing Vol.32 No5 p
p514 to 522 May 1991) "(hereinafter referred to as Reference 2).

As disclosed on page 516 of the above-mentioned document 2, (a) in an object-oriented database, an object identifier (OID) exists as a persistent object (data of the object-oriented database and exists across process boundaries. Plays an important role in identifying objects). Since the persistent object is managed on the secondary storage and operated on the main storage, the OID, the position of the persistent object on the secondary storage (Disk Address = disk address), and the position of the persistent object on the main storage (Memoty A
It is necessary to manage and convert the three values of ddress = memory address. (B) Since the persistent object is managed on the secondary memory and operated on the main memory, it is necessary to read the persistent object on the secondary memory once into the main memory for the operation. In addition, once the data is read into the main memory, the address of the main memory is used as much as possible to access the persistent object, which makes the reference of the persistent object efficient.

Further, in the contents disclosed on page 520 of Document 2, it is pointed out that (c) an OID hash table is necessary to access a persistent object in the main memory as a buffer. .. (D) It is pointed out that the persistent object is represented in the disk format on the secondary storage and in the memory format on the main memory. At the time of conversion of this expression format, the OID is converted, and the reference to the persistent object on the main memory can be easily traced.

By implementing the contents started in the literature 2, an object-oriented database system and a persistent programming (Persistent Program) are realized.
mingLanguage), you can speed up access to objects in the database. This means that the execution speed of the application program can be improved.

Therefore, as a technique for realizing the contents started in Document 2, a table (object table) of three values of OID of persistent object, disk address and memory address is stored on the secondary storage. There is a method in which a persistent object is accessed by storing and managing the table and referring to the table.

However, in such a conventional technique, the storage area (secondary storage area) is wasted due to the enlargement of the size of the object table, and the I (input) / O (output) for table reference increases. There is a possibility of
For this reason, the storage area cannot be effectively used, and improvement in processing efficiency cannot be expected.

Further, as a technique for realizing the above-mentioned object-oriented database system, (3) "" Concurrent processing control in an object-oriented database system "(Shojiro Nishio, Information Processing Vol.32 No5 pp540-54)
9 May 1991) ”(hereinafter referred to as Document 3) is known.

As disclosed on page 540 of Document 3, the function of parallel processing control in the database management system is essential for accessing data from a plurality of users. As a typical way to realize it 2
There is a locking system. In this two-phase locking method, a transaction locks data to schedule an operation execution sequence. Whenever you access data in a transaction, you lock it, and when the transaction ends, you unlock all the locks in that transaction. Therefore, if the persistent object cached in the main memory is valid across transactions, it is not necessary to duplicately read the persistent object in the main memory.

However, in the technique disclosed in Document 3, when a plurality of users update data, it is not known when the cache will be invalidated in the main memory. For this reason, the cached data that has already been cached is regarded as unreliable, and the necessary cached data has not been updated and can be used as is,
The required data must be cached again without using the cached data. That is, it is not possible to efficiently manage the cache in consideration of the parallel control by the transaction based on the lock, and the processing efficiency is poor.

A system that realizes an object-oriented database system is disclosed in Japanese Patent Laid-Open No. 3-13773.
0 has been disclosed

[0013]

As described above, in the above-described conventional object-oriented database system, the waste of the secondary storage area due to the enlargement of the size of the object table and the increase of I / O for table reference occur. There is a possibility that the storage area cannot be effectively used and the processing efficiency cannot be improved.

Further, in the technique disclosed in the above-mentioned document 3, when a user accesses data (object) cached by a certain transaction by another transaction, the cached data (object) is Despite being valid, the cached data is not used and the required data must be cached again. Because the data existing in the secondary storage area is assumed to be updated by multiple users, the cached data that has already been cached is considered to be unreliable. You have to recache. Therefore, efficient cache management cannot be performed in consideration of parallel control by transactions based on locks, resulting in poor processing efficiency.

By the way, in the memory format which is the representation format of the persistent object in the main storage area, not only the information obtained by converting the state of the persistent object represented in the disk format but also other data in the main storage area. It should have various values, such as a cache of, and flags indicating its own state. The reference to the persistent object in the main storage area can be efficiently realized by those values. Also, memory-style persistent objects should support the same association rules as the host language, the object language. By doing so, the operation model of the persistent object can be integrated with the operation model of the object-oriented language that is the host language.

However, since the above-mentioned documents do not disclose means for realizing them, in the past, a persistent object could not be efficiently represented in the main storage area.

An object of the present invention is to provide an object management method in an object-oriented database system capable of effectively utilizing a storage area.

Another object of the present invention is to provide an object management method in an object-oriented database system capable of efficiently managing a cache in consideration of parallel control by a transaction based on a lock.

Another object of the present invention is to provide an object management method in an object-oriented database system capable of efficiently expressing a persistent object in a main storage area.

[0020]

In order to achieve the above object, in the object management method in the object-oriented database system of the first aspect of the present invention, the secondary storage area stores the identifier of the persistent object and the persistent object.
A first table in which the position information on the next storage area is associated is stored, and the main storage area associates the identifier and the position information on the secondary storage area with the position information on the main storage area of the persistent object. The stored second table, and stores the first table
And the second table manages the persistent object.

In the object management method in the object-oriented database system of the second invention, in the first invention, when the position information on the main storage area is obtained from the identifier by referring to the second table, , Accessing the persistent object based on the location information, referring to the second table, and if the location information on the main storage area cannot be obtained from the identifier, continue to refer to the second table. Position information on the secondary storage area is obtained from the identifier, a permanent object is read from the secondary storage area to the main storage area based on this position information, and the main storage area of the read persistent object is also read. Is registered in the second table.

In the object management method in the object-oriented database system of the second invention, preferably, when the position information on the secondary storage area cannot be obtained from the identifier by referring to the second table, The feature is that it is determined that there is no persistent object corresponding to the identifier.

In the object management method in the object-oriented database system of the third invention, when locking the persistent object cached in the main storage area, it is judged whether or not the cache of the persistent object is effective, and this judgment is made. The feature is that data processing is performed according to the result.

In the object management method in the object-oriented database system of the third invention, preferably, information indicating whether the cache of the object is valid is added to the persistent object stored in the main storage area, and the information is added. It is characterized in that the validity of the cache is judged based on.

In the object management method in the object-oriented database system of the fourth invention, in the third invention, the cache of the persistent object is
If it is valid, the lock process is continued. If it is invalid, the desired persistent object is reloaded from the secondary storage area to the main storage area, the cache of the persistent object is validated, and then the lock is continued. Is characterized by.

In the object management method in the object-oriented database system according to the fifth aspect of the present invention, for the persistent object read from the secondary storage area to the main storage area, the volatile object including the position information in the main storage area, and the persistent It is characterized in that it is managed in combination with a handler that holds various information about the object.

[0027]

According to the present invention, only the identifier of the persistent object and the position information of the persistent object on the secondary storage area are stored in the first table stored in the secondary storage area and stored in the main storage area. The second table stored holds the identifier and the position information on the secondary storage area and the position information on the main storage area of the persistent object.
In the next storage area, only the area holding the information for managing the persistent objects in that storage area is used, and in the main storage area, the data of the entry in which the element reference to the first table is made. Since only the area for holding the storage area is used, the storage area can be effectively used.

According to the present invention, the second table stored in the main storage area is referred to, and if the position information on the main storage area cannot be obtained from the identifier, the second table is continuously stored. By referring to the identifier to obtain position information on the secondary storage area and reading the persistent object from the secondary storage area to the main storage area based on this location information, the persistent object is required. At this time, the data is cached in the main memory area, so that the main memory area can be effectively used.

Further, according to the present invention, when the position information on the secondary storage area cannot be obtained from the identifier by referring to the second table, it is determined that the persistent object corresponding to the identifier does not exist. Therefore, it is possible to determine whether or not the persistent object exists without accessing the secondary storage area, and thus the processing efficiency can be improved.

Further, according to the present invention, when locking the persistent object cached in the main storage area, it is determined whether the cache of the persistent object is valid, and if the result of the determination is that the persistent object is locked, it is locked. Continue the above process, and if it is invalid, select the desired permanent object from the above 2
After re-reading from the next storage area to the main storage area and enabling the cache of the persistent object, the lock is made to continue. Therefore, only when the cached persistent object is invalid, The data is read from the next storage area to the main storage area again, so that the processing efficiency can be improved.

Further, according to the present invention, regarding the persistent object read from the secondary storage area to the main storage area,
Since a volatile object that contains position information in the main memory area and a handler that holds various information about the persistent object are managed as a set, operations on the persistent object can be performed by referencing the handler in the main memory area. It can be performed.

[0032]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A first embodiment of an object management method according to the present invention will be described below with reference to the accompanying drawings of FIGS.

FIG. 1 is a functional block diagram showing a first embodiment of an object-oriented database system to which the object management method according to the first invention is applied.

In the figure, the object-oriented database system is an object-oriented database management system.
= OODBMS) 10, a secondary storage means 20, and a main storage means 30.

The secondary storage means 20 stores an object identifier (Object identity = OID) 21 of a persistent object, that is, a persistent object.
An object table 21 in which A and position information (Disk Address = disk address) 21B on the secondary storage means 20 of the persistent object are associated and registered, and a persistent object group 22 are stored.

In the main storage means 30, the OID 31A of the loaded persistent object, the position information (disk address) 31B of the persistent object in the secondary storage means, and the position information of the loaded persistent object in the main storage means 30 ( An object table 31 in which Memory Address = memory address 31C is associated and registered,
The loaded persistent object 32 is stored.

The object-oriented database management system 10 includes an object table management module 11,
It is composed of the persistent object management module 12. The object table management module 11 has an object table as a hash table, stores and manages the hash table in the secondary storage means 20, reads necessary parts into the main storage means 30 as necessary, and OID or disk data. Addresses, memory addresses are set, fetched, and deleted.

The object table (hash table) is managed as follows. When the object table exists in the secondary storage means 20 In this case, the object table holds only the OID for each persistent object and the position information (disk address) of the persistent object in the secondary storage means 20. ◆ When the object table exists in the main storage means 30 In this case, in the object table, the OID and disk address of each persistent object, and the position information of the persistent object existing in the main storage means 30 on the main storage means 30 ( Memory address).

Object table management module 11
Performs predetermined processing in response to an inquiry request or a write request for address information (memory address, disk address) from the persistent object management module 12. When requesting an inquiry for address information, the OID of the persistent object that is the operation target indicates the OID of the persistent object that is the operation target when writing the address information, and the address information of the persistent object. The persistent object management module 12 notifies the object table management module 11.

[When Address Information Inquiry Requested] In this case, in accordance with the contents of the address information inquiry request (contents of memory address inquiry or disk address inquiry) Access the object table of the storage means 20 or the main storage means 30,
The result obtained by this access (memory address or disk address address in the entry including the notified OID, or that there is no address) is returned to the persistent object management module 12 as a query result.

[When address information write request is issued] In this case, depending on the content of the address information write request (content of memory address write or disk address write), the secondary storage means 20 or Access the object table of the main storage means 30,
The notified address information is written in the entry including the notified OID of the corresponding table.

On the other hand, the persistent object management module 1
2 stores and manages persistent objects in the secondary storage means 20, reads them into the main storage means 30 as necessary, operates the persistent objects, and creates and deletes the persistent objects to create the main storage means 30 and 2 The data content of the next storage means 20 is updated. Further, it makes an inquiry request and a write request for address information (memory address, disk address) to the object table management module 11.

In response to this request, the object table management module 11 obtains the value of the object table in the main storage means 30 with the designated OID,
This will be returned to the persistent object management module 12.

The persistent object management module 12 performs the following processing according to the value which is a set of a memory address and a disk address.

[When the memory address is obtained from the specified OID] The persistent object is accessed at the returned memory address. [When the memory address cannot be obtained from the specified OID] (a) The permanent object obtained from the returned disk address is read and allocated on the main storage unit 30. (B) Request the object table management module 11 to register the memory address of the allocated persistent object in the object table. (C) Access the persistent object at that memory address. [When the disk address cannot be obtained from the specified OID] It is determined that there is no persistent object having that OID.

In this embodiment, the object-oriented database management system 10 is realized by executing a program (software) for realizing the above-mentioned functions by a control means such as a processor or a central processing unit. Of course, it can also be realized by hardware or firmware.

FIG. 2 is a block diagram showing the hardware structure for realizing the object-oriented database system of the embodiment shown in FIG. In the figure, the main storage device 210 fulfills the function of the main storage means 30 described above, and the secondary storage device 220 fulfills the function of the secondary storage means 20 described above. Data processor 2
A reference numeral 30 executes the object-oriented database management system 10 which is a program to perform a predetermined day process.
The display device 240 displays the result of data processing by the data processor 230.

Next, FIG. 3 shows a logical configuration of data managed by the object-oriented database management system 10.

In the example shown in this figure, the database file 310 is one logical object table 320.
In this table, the OID and the logical address of the persistent object are registered in association with each other. The object table 320 manages the persistent object group 330 which is the entity by the OID of each persistent object. Each persistent object is uniquely determined by the system O
I have an ID. Similarly, the database file 34
0 also has an object table 350, and this table manages the persistent object group 360. Data having such a logical structure is mapped and manipulated in a memory space.

Next, FIG. 4 shows an example of the structure of the object table on the secondary storage device.

In this embodiment, the object table is realized as a hash table and the OI is used as a key.
It has a disk address as D and a value. In the example shown in FIG. 4, the object table is stored at address 10000 on the secondary storage device, the persistent object with OID “100” exists at address 12345 on the secondary storage device, and the persistent object with OID “101” is present. It indicates that the object exists at the address 67890 on the secondary storage device.

The structure of the object table on the main memory is shown in FIG.

In this embodiment, the object table is realized as a hash table and the OI is used as a key.
It has a set of a disk address and a memory address as D and a value. In the example shown in FIG. 5, the object table exists at the address 100 on the main memory and the OID
The persistent object with "100" is 12 in the main memory.
The object existing at the address 3 and having the OID “101” does not exist in the main memory. In this case, since there are probes (references to elements) for the entries with OIDs “100” and “102”, only those entries exist.

Next, the process of obtaining the memory address from the OID of the persistent object by the object-oriented database management system 10 will be described with reference to the flowchart shown in FIG.

From the application program (user) to the object-oriented database management system 10
When the ID is given, the persistent object management module 12 inquires the object table management module 11 about the address information by designating the OID from the application program.

Object table management module 11
Then, based on the given OID, the OID is given as a key of the object table, and the value which is a set of the disk address and the memory address is obtained (step 6).
01), and returns this as a query result to the persistent object management module 12.

The persistent object management module 12 determines whether or not the value of the value which is the inquiry result is "0" (step 602). If the value is “0” (in this case, there is no entry in which the given OID is registered), it is determined that there is no persistent object with the specified OID (step 603), and then the process ends.

When the value is not "0" in step 602 (in this case, it means that there is an entry in which the given OID is registered, and at least the disk address is registered in that entry). Is
It is determined whether or not the value memory address is "0" (step 604).

Here, if the memory address value is not "0", the persistent object is buffered in the main memory, so that memory address is returned to the requesting application program (step 60).
5).

In step 604, the memory address is "0".
, It means that the persistent object is not buffered in the main storage device, so the persistent object management module 12 stores the persistent object in the secondary storage device based on the address of the value disk address. It is read into the storage device and buffered (step 60
6) The read persistent object is allocated to the main storage device and written therein (step 607). After that, the memory address of the persistent object just allocated is passed to the object table management module 11 to request the writing of the address information.

Object table management module 11
Then, the allocated address (memory address) on the main storage device is registered in the value memory address of the object table (step 608).

When step 608 ends, the persistent object management module 12 returns the allocated address (memory address) on the main storage device to the application program (step 609).

In the above-mentioned example, the access of the objects existing in one data file has been described, but since the references between the objects across the database files may occur, the logical structure of the data in that case will be described next. Will be explained. Its logical structure is shown in FIG.

In the example shown in this figure, it is shown that objects are referenced across the two database files shown in FIG. That is,
The persistent object 720 with OID “710” in the database file 340 and the persistent object 74 with OID “730” in another database file 310.
Refers to 0.

In order to realize the reference between the objects across the database files as described above, in this embodiment, the database file is provided with one external object table in addition to one object table. ing. The external object table is a hash table having the OID of the persistent object of another database file referenced by the persistent object in the database file to which its own table belongs as a key and the other database file as a value. .. For example, the OID and the logical address of the database file are registered in the external object table in association with each other.

In accessing the data of such data structure, the object-oriented database management system 10 first accesses the object table when the OID is given. If the persistent object corresponding to the given OID is not found here, the external object table is accessed next. If no corresponding persistent object is found in this table, it means that there is no persistent object corresponding to the given OID.

Here, FIG. 8 shows a data structure for realizing the reference between objects in the example shown in FIG. In the figure, an external object table 810 exists in the database file 310, and an external object table 8 exists in the database file 340.
There are 20. External object table 820
Corresponds to the OID of the persistent object 740 referenced by the persistent object 720, that is, “730”,
Information indicating the database file 310 to which the persistent object 740 belongs, that is, a logical address is registered. Data having such a logical structure is mapped and manipulated in a memory space.

Now, if "730" is given as the OID, the object-oriented database management system 10 obtains the value (persistent object) of the object table 350 with the OID. However, since the corresponding persistent object is not registered in that table, the value (database file) of the external object table 820 with the OID is next.
You will get The table has an OI of “730”
Since the information (disk address) indicating the database file 310 is registered corresponding to D, the object-oriented database management system 10 accesses the database file 310 based on the disk address, and the object with the OID of “730”. The value (persistent object) of the table 320 will be obtained. Since the disk address of the persistent object 740 is registered in this table in correspondence with the OID of "730", the persistent object 740 can be referenced based on the disk address.

Next, in the case where there is a possibility that an object reference across the database file may occur,
Referring to FIG. 9, a reference process of referring to a persistent object by the object-oriented database management system 10 will be described.

FIG. 9 is a flowchart of a processing procedure for obtaining a memory address from the OID of a persistent object by using the object table and the external object table in the persistent object management module 12.

From the application program (user) to the object-oriented database management system 10
When the ID is given, the persistent object management module 12 inquires the object table management module 11 of the address information (object table) by designating the OID from the application program.

Object table management module 11
Gives the OID as a key of the object table based on the given OID, and obtains the value which is a set of the disk address and the memory address (step 90).
1), this is returned to the persistent object management module 12 as a query result. The persistent object management module 12 determines whether the value that is the inquiry result is "0" (step 902). If the value is not 0, step 6 of the processing procedure shown in FIG.
The same processing as 04 to 609 is performed (step 903).
~ 908).

If the value is "0" in step 902, the persistent object management module 12 queries the object table management module 11 for the address information (external object table) by designating the OID from the application program. I do.

Object table management module 11
Then, based on the given OID, the OID is given as a key of the external object table, the value of the database file is obtained (step 909), and this is returned to the persistent object management module 12 as a query result.

The persistent object management module 12 judges whether or not the value database file as the inquiry result is "0" (step 91).
0).

In step 910, when the obtained value is "0", it is determined that there is no persistent object having the specified OID (step 911), and then the process is terminated, and in contrast, the profit is obtained. If the obtained value is not “0”, the persistent object management module 12 is requested to inquire the address information of the object table.

The persistent object management module 12 obtains a value, which is a set of a disk address and a memory address, from the designated OID in the object table of the database file represented by the OID (step 911), and returns this as an inquiry result. ..

Object table management module 11
Then, it is determined whether or not the resulting value is "0" (step 912). If the value is 0, the process proceeds to step 911, and if the value is not "0", the process returns to step 903.

As described above, in this embodiment, the object table is realized by the hash table, so that the three values of the OID, the disaddress, and the memory address of the persistent object, which is the original intention of the object, can be managed. It has the following effects.

(1) The object table holds only the ODI and the disk address on the main memory, and the memory address of the persistent object existing on the main memory. It can be used as a management buffer.

(2) A certain OI is determined by using the object table and determining whether or not there is a value in the set.
The existence of a persistent object with D can be determined. When the value of the set does not exist, it can be determined that the persistent object does not exist.

(3) Since the object table holds only the correspondence between the ODI and the disk address on the secondary storage, the storage area on the secondary storage is not wasted even if the object table becomes large. Also, since the object table does not need all the data in the main memory and holds only the data of the entry that has a probe (reference of element), only the necessary memory area in the main memory exists. Because it does, it is not oppressed.

Next, a second embodiment of the object management method according to the present invention will be described with reference to the accompanying drawings of FIGS.

FIG. 10 is a functional block diagram showing a second embodiment of the object-oriented database system to which the object management method according to the present invention is applied.

In the figure, the object-oriented database system is an object-oriented database management system 1010, secondary storage means 1020, main storage means 1.
030.

Data such as persistent objects and object tables are stored in the secondary storage means 1020, and data loaded from the secondary storage means 1020 is stored in the main storage means 1030.

The object-oriented database management system 1010 includes a persistent object management module 101.
1, a transaction module 1012.

Persistent Object Management Module 1011
Is an operation function (hereinafter referred to as a valid / invalidity judgment operation function) 1011A for determining whether the cache of a persistent object is valid or invalid, and a persistent object secondary storage means 1
It has an operation function (referred to as a read operation function) 1011B that reads from 020 to the main storage unit 1030 and an operation function (referred to as a cache invalidation operation function) 1011C that invalidates the cache of the persistent object, and executes these operation functions. Then, the persistent object is stored in the secondary storage means 1
It is stored and managed in 020, and if necessary, the main storage means 103
Read to 0, manipulate persistent objects,
The main storage means 10 is generated by the generation or disappearance of the persistent object.
30 and the data contents of the secondary storage means 1020 are updated.
The persistent object cache is managed by the persistent object management module 1011.

The transaction module 1012
Operation function 1012A to lock the persistent object
And the operation function 1012 to unlock the persistent object
B and an operation function 1012C that performs processing for abnormal termination of the transaction, and executes these operation functions to perform parallel control based on the lock of the two-phase locking system. The operation function 1012C is, for example, a process of re-executing the transaction or notifying the application program (user) of the abnormal termination when the transaction abnormally ends due to a system error or transaction deadlock. There is.
Since the parallel control based on the lock of the two-phase locking system can be realized by using a well-known technique, its description is omitted here.

In the object-oriented database management system 1010 having such a configuration, the operation functions of the persistent object management module 1011 and the operation functions of the transaction module 1012 are in a close relationship.

That is, both the operation function 1012A and the operation function 1012B are the valid / invalid judgment operation function 1011.
A, operation function 10 related to read operation function 1011B
12C is a valid / invalid judgment operation function 1011A, a read operation function 1011B, and a cache invalid operation function 1011.
Related to C.

In this embodiment, the object-oriented database management system 1010 is realized by executing a program (software) for realizing the above-mentioned functions by a control means such as a processor or a central processing unit. .. Of course, it can also be realized by hardware or firmware.

The hardware structure for realizing the object-oriented database system of the embodiment shown in FIG. 10 is the same as the structure shown in FIG. It is composed of a data processor that executes the object-oriented database management system 1010, a main storage device that functions as the main storage unit 30, a secondary storage device that functions as the secondary storage unit 20, and a display device.

In this embodiment, when representing one persistent object, the representation format on the main storage device is different from that on the secondary storage device. FIG. 11 shows an example of these expression formats. FIG. 11A shows a persistent object on the main memory,
FIG. 11B shows a persistent object on the secondary storage device.

Persistent objects in main memory are shown in FIG.
As shown in 1 (a), it has class information 1110, attribute value information 1120, and information (for example, flag) 1130 indicating whether or not the cache is valid. In contrast,
The persistent object in the secondary storage device information is shown in FIG.
, Class information 1110 and attribute value information 1
It has 120. However, it does not have information indicating whether the cache is valid.

As described above, the information indicating whether the cache is valid or not is provided only for the persistent object in the main storage device in order to determine whether or not the cache of the persistent object is valid. Therefore, it is not necessary to provide that information in the persistent object in the secondary storage device information.

The information indicating whether the cache is valid or not is referred to by the validity / invalidity judgment operation function 1011A. If it is determined to be invalid here, the read operation function 1
By 011B, the corresponding persistent object is read from the secondary storage device, and a flag indicating that the cache is valid is set in the persistent object. The information indicating whether the cache is valid is changed from valid to invalid by the cache invalidation operation function 1011C.

Next, the transaction module 101
The processing procedure of the operation for locking the persistent object in 2 will be described with reference to the flowchart shown in FIG. When the operation function 1012 executes a lock operation, the valid / invalid determination operation function 1011A is called at the beginning of the lock operation. The valid / invalid determination operation function 1011A determines whether or not the cache of the persistent object is valid based on the flag indicating whether or not the cache of the persistent object on the target main storage device is valid (step 1201). If it is invalid, the read operation function 1011B is called.

In the read operation function 1011B, the corresponding persistent object is read from the secondary storage device (step 1202), and the flag of the persistent object cache on the main storage device is validated (step 120).
3) Further, the operation function 10 indicates that the cache is enabled.
Notify 12

If the cache indicates that the cache is valid, the operation function 1012 continues the lock operation based on the two-phase locking method (step 1204). Step 120
If the cache is valid in step 1, the process proceeds to step 1204.

Note that the flag of the cache of the persistent object in the main memory is invalidated (a) when the state of the persistent object is changed in a certain transaction and the transaction ends abnormally. This is the case when the persistent object on the main memory is updated, but the transaction ended abnormally, so the persistent object before the change must be operated. This is because As a result, the persistent object before updating is read from the secondary storage device into the main storage device. (B) When the state of a persistent object is changed by a transaction in the main storage device of a different machine (different object-oriented database system) and the transaction ends normally, so that the persistent object in the secondary storage device is updated. Is.

In any case, the transaction module 1012 detects these states and instructs the persistent object management module 1011 to invalidate the cache.

Next, the processing in the case of using a persistent object cached in the main storage device across transactions will be described with a specific example.

FIG. 13 is a diagram for explaining a process when a persistent object cached across transactions is used.

In FIG. 13, Obj1 and Obj1
´ indicates a persistent object, t1, t2, ..., t13
Indicates time, and the relation of t1 <t2, ..., <t13 is established.

User 1 is now in transaction Tr
Assuming that a cached persistent object is operated across 1 and transaction Tr2,
At this time, transaction Tr1 and transaction T
Assume that user 2 executes transaction Tr3 with r2.

In this embodiment, it is assumed that the client-server model is used, and the user 1 shown above as the client (application program),
User 2 and the database (secondary storage device) are used as servers. To implement this client-server model, for example, a remote procedure call (RPC) is used. Since this RPC itself is a well-known technique, its explanation is omitted here.

When the user Tr1 opens the transaction Tr1 at time t1, locks it at time t2, reads Obj1 from the secondary storage device into the main storage device, and caches it, the Obj1 becomes valid. Obj at time t3
It is assumed that the transaction Tr1 is normally terminated by referring to 1 (reference), unlocking (releasing the lock) at time t4, committing at time t5. In this case, the main storage device and the secondary storage device (server) of the machine to which the user 1 belongs are both Obj1.

Next, in the user 2, the transaction Tr2 is opened at time t6 and locked at time t7.
When Obj1 is read from the secondary storage device into the main storage device and cached, the Obj1 becomes valid. Obj1 is updated at time t8, unlocked at time t9,
Commit at time t5, transaction T
It is assumed that r2 ends normally. In this case, the main storage device and the secondary storage device (server) of the machine to which the user 2 belongs are both Obj1 '.

Subsequently, the user 1 opens the transaction Tr2 at time t11 and locks it at time t12.
In this case, since Obj1 is updated by the user 2, this corresponds to (b) when the flag of the cache of the persistent object on the main storage device described above is invalidated. Therefore, at the time t12 on the user 1 side. At the time of locking at 1, the information indicating whether the cache of Obj1 cached in the main storage device is valid is changed from valid to invalid.
At this time, since the cached cache of Obj1 is invalid, the corresponding Obj1 ′ is reread from the secondary storage device (server) onto the main memory and the lock operation is continued. When the predetermined operation is completed, unlock the
Commit at t13.

In case (b) of invalidating the flag of the persistent object cache on the main storage device described above, when the user 1 (client) notifies the server (secondary storage device) of the lock. The server returns to the user 1 that the target data (Obj1 in this case) has been changed. At this time, user 1
The flag indicating whether the cache of Obj1 is valid is updated from valid to invalid. After that, the user 1 will go to load the corresponding data (Obj1 ′ in this case). On the other hand, in the case of invalidating the flag of the persistent object cache on the main memory described above (a), the client indicates the flag indicating whether the cache of the object of the abort target is valid or not. Will be updated from valid to invalid. The subsequent processing is the same as the above processing.

When the user 2 side refers to Obj1 at time 8 of the transaction Tr3 and the state of Obj1 does not change and the transaction Tr3 ends normally, the cached Obj1 on the user 1 side is Since it is valid (because Obj1 is referenced at time 8 of transaction Tr3), the lock operation can be continued as it is.

As described above, according to this embodiment,
Check whether cache in main memory is valid or invalid 2
Realized as part of the data lock in the phase locking system,
Furthermore, when it is determined that the cache is invalid at the time of locking, the persistent object is reloaded from the secondary memory to the main memory to continue the lock operation. so,
Cache can be used effectively across transactions and duplicate reading of persistent objects can be prevented. Further, concurrency control allows multiple users to access the data consistently.

Next, a third embodiment of the object management method according to the present invention will be described with reference to the accompanying drawings of FIGS.

As a feature of the present invention, a persistent object is an object generated by a constructor (provided by an object-oriented language (a volatile object (volati
le Object)) and various information that should be added to the persistent object (database file to which it belongs, class definition, cache valid / invalid flag, physical location of the object on the secondary storage device, etc.) It is realized by the memory format as a set of.

The position information on the main memory of the persistent object is represented as the address of the handler, and each handler holds the address of the corresponding volatile object.

Further, the reference from the persistent object to the persistent object should be such that the address of the handler constituting the referenced persistent object is held as the attribute value of the volatile object constituting the referenced persistent object in the main memory. Has been realized in.

Further, in deleting a persistent object, only the constituent volatile objects are released from the area on the main memory, and while the deleted persistent object is referenced by another persistent object, the deleted persistent object is deleted. The handler that constructs the object sets a flag indicating that the persistent object has been deleted, does not release the area in the main memory, and when there is no reference to the deleted persistent object from other persistent objects, The area on the main memory of the handler that constitutes the deleted persistent object is released.

FIG. 14 shows a memory format which is a representation on the main memory of a persistent object.

The persistent object is represented by a combination of a handler 1410 and a volatile object 1420 on the main memory. The handler 1410 represents a persistent object on the main memory, and the handler 1410 refers to the corresponding volatile object 1420. Handler 1410
Indicates the location 1411 of the corresponding volatile object, the identifier 1412 of the persistent object, the database file 1413 to which it belongs, the class definition 1414, the location 1415 when it is saved in the secondary storage device, and whether or not the main storage cache is valid. It has information such as a flag 1416 indicating the flag and a flag 1417 indicating whether or not the persistent object still exists.

The volatile object 1420 is exactly the same as a normal volatile object which is generated by a constructor given from its class definition and has attribute value information 1421 and which is not an element constituting a persistent object. Therefore, the connection rules of the object-oriented language, which is the host language, are similarly applied. Changing the state of a persistent object in main memory means
This means changing the state (attribute value) of the constituent volatile objects.

FIG. 15 shows a representation method on the main memory of a reference from a persistent object to a persistent object. Attributes of persistent object 1 and persistent object 2
Can be realized by setting the address of the handler 2 to the attribute value 2 of the volatile object 1.

Next, in deleting the persistent object, the procedure for releasing the area on the main memory will be described with reference to the flowchart shown in FIG.

In releasing the area in the main memory, the area in the main memory of the volatile object is released (step 1601), and then it is judged whether or not another persistent object refers (step 1601). 1602).

Here, if it is not referred to, the area on the main memory of the constituent handler is released (step 1).
603). If not referenced in step 1602,
A flag indicating the disappearance of the persistent object is set in the constituent handler (the flag 1417 indicating whether or not the persistent object shown in FIG. 14 still exists) (step 16).
02) and returns to step 1602.

Next, the processing for explaining the reference from the persistent object to another persistent object will be described with reference to a concrete example shown in FIG.

Here, an Object whose OID is "10"
Consider the case where A refers to Object B whose OID is “20”.

On the secondary storage, the OID is "10".
ObjectA holds the OID (20) of ObjectB.

In the main memory, ObjectA is represented by a handler existing at a memory address of address 123 and a volatile object existing at a memory address of address 456, while ObjectB is expressed at a memory address of address 789. It is represented by the existing handler and the volatile object existing at the memory address of address 890.

Here, the memory address at address 123 is the position information of the handler, and also indicates the position information on the main memory of ObjectA. The handler holds the address (address 456) of the corresponding volatile object. For the volatile object, the address of the handler that constructs ObjectB referenced by ObjectA (78
9) is held as an attribute value.

Similarly, the memory address at address 789 is the position information of the handler, and also indicates the position information on the main memory of ObjectB. The handler holds the address (address 890) of the corresponding volatile object.

Further, the reference from the persistent object to the persistent object is such that the address of the handler constituting the referenced persistent object is held as the attribute value of the volatile object constituting the referenced persistent object in the main memory. Has been realized in.

As described above, according to this embodiment, the persistent object on the main memory is managed by the combination of the volatile object and the handler. Can follow language binding rules. In addition, the handler uses various information as a flag indicating the cache of other data in the main memory and the status of itself (database file to which it belongs, class definition, cache valid / invalid flag, object secondary storage device). Physical location, etc.).

[0134]

According to the present invention, the first table stored in the secondary storage area holds only the identifier of the persistent object and the position information of the persistent object in the secondary storage area, and the main storage area The second table stored in the table stores the identifier and the position information in the secondary storage area and the position information in the main storage area of the persistent object. Only the area that holds the information for managing the persistent objects in the area is used, and in the main storage area, only the area that holds the data of the entry that referred to the element for the first table is used. .. If the second table stored in the main storage area is referred to and the position information in the main storage area cannot be obtained from the identifier, the second table is continuously referred to from the identifier to the secondary storage. Since the position information on the area is obtained and the persistent object is read from the secondary storage area to the main storage area based on this position information, the storage area can be effectively used.

If the position information in the secondary storage area cannot be obtained from the identifier by referring to the second table, it is determined that the persistent object corresponding to the identifier does not exist. It is possible to determine whether or not a persistent object exists without accessing the next storage area, thus improving the processing efficiency.

Further, according to the present invention, when locking a persistent object cached in the main storage area, it is determined whether the cache of the persistent object is valid, and if the result of the determination is that it is locked, Continue the above process, and if it is invalid, select the desired permanent object from the above 2
After re-reading from the next storage area to the main storage area and enabling the cache of the persistent object, the lock is continued. Therefore, if the cached persistent object is invalid, the corresponding persistent object is 2 Since the data will be read again from the next storage area to the main storage area, the cache can be effectively used across transactions and duplicate reading of persistent objects can be prevented. Further, concurrency control allows multiple users to access the data consistently. Therefore, it is possible to efficiently manage the cache in consideration of the parallel control by the transaction based on the lock.

According to the present invention, the persistent object read from the secondary storage area to the main storage area is
Since a volatile object that contains position information in the main memory area and a handler that holds various information about the persistent object are managed as a set, operations on the persistent object can be performed by referencing the handler in the main memory area. It can be performed.

Further, according to the present invention, since the persistent object on the main memory is managed by the combination of the volatile object and the handler, the persistent object can follow the association rule of the object-oriented language which is the host language by the volatile object. it can. Since the handler can know the information necessary to operate the persistent object, it is possible to improve the reference efficiency of the reference to the persistent object in the main memory.

[Brief description of drawings]

FIG. 1 is a functional block diagram showing a first embodiment of an object-oriented database system to which an object management method according to the present invention is applied.

2 is a block diagram showing a hardware configuration for implementing the system shown in FIG.

FIG. 3 is a diagram showing a logical data structure of data managed by the object-oriented database management system in the first embodiment.

FIG. 4 is a diagram showing a data structure of an object table on a secondary storage device in the first embodiment.

FIG. 5 is a diagram showing a data structure of an object table in a main storage device according to the first embodiment.

FIG. 6 is a flowchart showing an operation of a persistent object access process by the object-oriented database management system in the first embodiment.

FIG. 7 shows a case where a persistent object is referenced across database files in the first embodiment.
The figure which shows the logical data structure of the data.

8 is a diagram showing a data structure for realizing a reference between persistent objects in the data structure shown in FIG. 7. FIG.

FIG. 9 is a flowchart showing the operation of reference processing when a persistent object is referenced across database files by the object-oriented database management system in the first embodiment.

FIG. 10 is a functional block diagram showing a second embodiment of an object-oriented database system to which the object management method according to the present invention is applied.

FIG. 11 is a diagram for explaining an expression format on a main storage device and an expression format on a secondary storage device of a persistent object in the second embodiment.

FIG. 12 is a flowchart showing a processing procedure of an operation for locking a persistent object in the transaction module according to the second embodiment.

FIG. 13 is a diagram for explaining a procedure for operating a persistent object cached across transactions in the second embodiment.

FIG. 14 is a third object management method according to the present invention.
For explaining the representation format on the main memory of the persistent object in the embodiment of FIG.

FIG. 15 is a diagram for explaining a reference from a persistent object to another persistent object in the third embodiment.

FIG. 16 is a flowchart showing a processing procedure for releasing an area on the main memory when deleting a persistent object in the third embodiment.

FIG. 17 is a diagram showing a specific example for explaining a reference from a persistent object to another persistent object in the third embodiment.

[Explanation of symbols]

10, 1010 ... Object-oriented database management system, 11 ... Object table management module,
12, 1011 ... Persistent object management module, 2
0, 1020 ... Secondary storage means, 21, 30 ... Object table, 22 ... Persistent object group, 30, 103
0 ... Main storage means, 32 ... Persistent object, 210 ... Main storage device, 220 ... Secondary storage device, 230 ... Data processor, 240 ... Display device, 1012 ... Transaction module, 1410 ... Handler, 1420
… Volatile objects.

Claims (5)

[Claims] 1. An object-oriented database system for reading a persistent object as information stored in a secondary storage area into a main storage area, wherein an identifier of the persistent object and a secondary of the persistent object are stored in the secondary storage area. A first table in which the position information on the storage area is associated is stored, and the main storage area stores the position information on the identifier and the secondary storage area and the position information on the main storage area of the persistent object. An object management method in an object-oriented database system, which stores a corresponding second table, and manages the persistent object by the first and second tables. 2. When the position information on the main storage area is obtained from the identifier by referring to the second table,
The persistent object is accessed based on the position information, the second table is referred to, and if the position information on the main storage area cannot be obtained from the identifier, the second object continues.
Position information on the secondary storage area is obtained from the identifier by referring to the table of FIG. 1, the persistent object is read from the secondary storage area to the main storage area based on the positional information, and the read persistent object is read. 2. The object management method in the object-oriented database system according to claim 1, wherein the position information on the main storage area of is registered in the second table. 3. An object-oriented database system for reading a persistent object as information stored in a secondary storage area into a main storage area, when locking the persistent object cached in the main storage area, An object management method in an object-oriented database system, comprising: determining whether the cache of the persistent object is valid and performing data processing according to the determination result. 4. When the cache of the persistent object is valid, the lock processing is continued, and when it is invalid, a desired persistent object is reloaded from the secondary storage area to the main storage area, and the persistent object is stored. 4. The object management method in an object-oriented database system according to claim 3, wherein the lock is continued after the cache is validated. 5. An object-oriented database system for reading a persistent object as information stored in a secondary storage area into a main storage area, wherein the persistent object is read from the secondary storage area onto the main storage area. An object management method in an object-oriented database system, characterized in that management is performed by a set of a volatile object including position information on the main storage area and a handler having various information about the persistent object.