JP2003167765A - Information processor and processing method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an information processor and a processing method capable of improving the response when referring to a database, and a computer- readable memory. <P>SOLUTION: The processor comprises a database operation means for operating a database 16001; a database cache management means for managing a database cache 15002; a transaction operation means for operating a transaction for managing a series of streams of operating the database 15001; and a transaction cache management means for managing a transaction independent cache 15004 and a transaction common cache 15006. According to such a structure, the response is improved while realizing an expected operation every isolation. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an information processing apparatus and method for managing a database, and a computer-readable memory.

[0002]

2. Description of the Related Art In the prior art, processing was performed with a transaction as an independent unit. In addition, the degree of interference between transactions is specified by the isolation level, and the type of data held in the cache for each transaction and the modification / reference restrictions from other transactions are modified.

FIG. 100 is a diagram showing the presence / absence of a general cache in each processing stage of a transaction.
In FIG. 100, the object cache being changed is used to hold the information being changed, and is finally determined at the time of Commit. The acquired Object cache is used to hold the acquired information. The acquired object group cache holds the information of the object group together with the acquisition condition.

Further, FIG. 101 is a diagram showing the level of operation permission to the cache at each stage of a transaction. For example, inconsistency occurs when the object in the middle of change is acquired (changed later) by another transaction. In the example below, from deposit \ 50,000, transaction 1 will generate \ 10,000, and transaction 2 will generate \ 50,0
The contradiction that 00 is withdrawn occurs.

Tr1-1.Object (\ 50,000,12 / 1) acquisition Tr1-2.Update date and time (12/27) entry Tr2-1.Object (\ 50,000,12 / 1) acquisition Tr1-3.After withdrawal Enter amount (\ 50,000- \ 10,000 = \ 40,000) Tr1-4. Commit changes Tr2-2. Enter amount after withdrawal (\ 50,000- \ 50,000 = \ 0) Enter Tr1-2 first Inconsistency can be avoided by prohibiting changes by other transactions when the changes are started.

[0006] Further, since the acquired Object is acquired (changed later) by another transaction, a contradiction occurs. The above example corresponds to the case of being acquired by the transaction 2 between Tr1-1 and Tr1-2.

[0007] Further, the object group being changed is acquired (changed later) by another transaction, which causes inconsistency. In order to avoid this contradiction, it is necessary to prohibit the addition / deletion / update of Objects that affects the acquisition conditions of Objects.

In order to avoid the above contradiction, for example, as shown in FIGS. 100 and 101, when the isolation level is Read Uncommitted, only the object of current interest is held in the cache and simultaneously written by another transaction. Was prohibited. Also, Read C
In the case of ommitted, in addition to the above, objects in the process of being modified are also retained in the cache, and at the same time, reading by other transactions is prohibited. In addition, in the case of Repeatable Read, in addition to the above, the acquired objects are also held in the cache, and at the same time, writing by other transactions is prohibited. In addition, in the case of Serializable, in addition to the above, also retain the acquired objects in the cache,
At the same time, writing that affects the acquisition result is prohibited, and reading that affects the acquisition result that is being changed is prohibited.

FIG. 102 shows a general database management technique by two independent transactions.
It is a figure showing an example of signs that the same object stored in the same database is acquired. The transaction 1 indicated by 20501 and the transaction 2 indicated by 20502 are Obje converted from the storage image of Object 1 stored in the same database 20503.
I got ct1. Here, when Object1 is acquired by transaction 1, (1) the storage image of Object1 is converted into Object1 which is a form accessible by transaction, and (2) converted Object1
Is obtained. On the other hand, when Object 1 is acquired by transaction 2 after that, (3) the stored image of Object 1 is converted again to Object 1 which is a form accessible by the transaction, and (4) the converted Obje.
ct1 is acquired.

Therefore, even though the same object stored in the same database is acquired, the stored image of the object must be converted into a form accessible by a transaction each time.

On the other hand, FIG. 105 shows an example of a state in which the same object group stored in the same database is acquired under the same search condition by two independent transactions in a general database management technique. It is a figure. A transaction 1 indicated by 20801 and a transaction 2 indicated by 20802 are object groups (Object1, Object2, Object3, ..., Object1) stored in the same database 20803.
0) has been acquired. Here, when the object group is acquired by the transaction 1, (1) the object group that matches the specified search condition is searched, and (2)
The searched object group is acquired. On the other hand, when the object group is acquired by the transaction 2, (3) the object group that matches the specified search condition is searched again, and (4) the searched object group is acquired.

As described above, although the same database was searched under the same search condition, the object group had to be searched again each time.

[0013]

In the technique described with reference to FIG. 102, it is necessary to reconvert the same stored image in the database into a form that can be accessed by a transaction each time, which causes a decrease in response. Has become.

Therefore, in the database management technique shown in FIG. 103, the isolation level is set to Repeatable Read.
Or, by specifying as Serializable, the method of retaining the previously acquired object in the cache for each transaction is used. By configuring in this way, avoiding re-conversion from the stored image of the object,
It is possible to avoid a decrease in response. But the cache holding the previously retrieved objects is
Since it is impossible to refer to the same transaction, it is not possible to solve the above-mentioned problem that occurs when referring to the same object from multiple transactions.

Further, in the database management technique shown in FIG. 104, each transaction directly accesses the storage image of the object stored in the database, thereby avoiding reconversion of the form. However, in order for each transaction to actually refer to the desired information from the stored image of the object, it was necessary to re-analyze the stored image each time. For example, when the stored image stored in the database is encrypted, it needs to be re-decoded each time, and it is inevitable that the response is deteriorated and the problem cannot be solved.

On the other hand, in the technique described with reference to FIG. 105, it is necessary to re-search each time in order to obtain an object group that matches the specified condition from the database, which causes a decrease in response. .

Therefore, in the data management technique shown in FIG. 106, a method of holding the previously acquired object group in the cache for each transaction by designating the isolation level as Serializable is used. As a result, it is possible to avoid re-search under the same condition and avoid a decrease in response. However, the cache that holds the previously acquired objects cannot be commonly referenced between transactions, so the problem that occurs when searching under the same conditions from multiple transactions as described above Could not be resolved.

Further, in the data management technique shown in FIG. 107, the objects are not treated as an object group, but objects that meet the specified conditions are acquired one by one. However, with this, you have to search each time you get one object, so it is inevitable that the response will deteriorate.
The above problems could not be solved.

The present invention has been made in view of the above problems, and an object thereof is to improve the response at the time of acquisition of the same object and a group of objects searched under the same condition.

[0020]

An information processing apparatus according to the present invention for achieving the above object has the following configuration.
That is, an information processing device that manages a database,
Generating means for generating a transaction for accessing an object managed by the database,
First cache means for caching the object acquired and edited by the transaction generated by the generating means, and second cache for providing a cache memory for the database and caching the object acquired from the database by the transaction And means.

Further, an information processing method according to the present invention for achieving the above object is an information processing method for managing a database, which includes a generating step for generating a transaction for accessing an object managed by the database. A first cache step for caching the object acquired and edited by the transaction generated in the generating step, and a second cache step for providing a cache memory for the database and caching the object acquired from the database by the transaction And a cash process.

[0022]

Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

<First Embodiment> FIG. 1 is a block diagram showing the hardware arrangement of an information processing apparatus according to the first and second embodiments.

In FIG. 1, reference numeral 1 is an input unit for inputting information (data). Reference numeral 2 denotes a CPU, which performs arithmetic operations for various processes, logical judgments, etc., and controls each component connected to the bus 6. An output unit 3 outputs information (data). The output unit 3 includes a display such as an LCD and a CRT, and a recording device such as a printer. Reference numeral 4 denotes a program memory, which is a memory for storing a program for control by the CPU 2 including a processing procedure of a flowchart described later. The program memory 4 is a ROM
Or a RAM in which a program is loaded from an external storage device or the like. A data memory 5 stores data generated in various processes and also stores data of a database (DB) described later. The data memory 5 is, for example, a RAM, but the data of the database is loaded from a non-volatile external storage medium prior to the processing, or is referred to whenever necessary. Reference numeral 6 designates an address signal for instructing each component to be controlled by the CPU 2, a control signal for controlling each component, and a bus for transferring data exchanged between each component.

FIG. 2 is a flowchart showing the processing executed by the information processing apparatus of the first embodiment. FIG. 2 shows a procedure from system startup to database processing start.

As shown in FIG. 2, when the system is started, the system starting process is executed in step S201 to initialize various data. Next, step S20.
In step 2, event waiting processing is executed to wait for the occurrence of an event corresponding to a user operation, an event corresponding to a change in various states, or the like. When the occurrence of an event is detected, the process proceeds to step S203.

In the following step S203, step S
It is determined whether the event detected in 202 is a power-off instruction. If the event is not the instruction to turn off the power (NO in step S203), step S204
Proceed to. In step S204, it is determined whether the event detected in step S202 is a database processing operation instruction. If it is not a database processing operation instruction (NO in step S204), step S202
Return to. On the other hand, if the instruction is a database processing operation (YES in step S204), the process advances to step S205 to execute the corresponding database process, and then to step S204.
Returning to 202, the above processing is repeated.

On the other hand, if the event is an instruction to turn off the power in step S203 (YES in step S203).
S), the process proceeds to step S206, the system end process is executed, and then the process ends.

Next, an example of the database processing screen displayed in the database processing of step S205 will be described with reference to FIG.

FIG. 3 is a diagram showing an example of the database processing screen of the first embodiment. Reference numeral 31 is a button for instructing to start the database server service. Reference numeral 32 is a button for instructing the creation of a database. 33 is a button for instructing the generation of a transaction. 34 is a button for instructing the display of class definition information. Reference numeral 35 is a button for instructing to display the storage information of the object. Reference numeral 36 is a button for instructing the end of database processing.

Details of the database processing in step S205 will be described below with reference to FIG.

FIG. 4 is a flowchart showing details of the database processing in step S205 of the first embodiment.

When step S205 in FIG. 2 is started,
That is, when the database process is activated, first, an initialization process is executed in step S401 to initialize various internal data. Next, the screen display process of step S402 is executed to display the database processing screen described in FIG. In a succeeding step S403, event waiting processing is executed to wait for the occurrence of an event corresponding to a user operation. When the occurrence of an event is detected, the process proceeds to step S404.

In step S404, it is determined whether or not the event generated in response to the operation performed by the user is an end instruction. If the event is an end instruction (YES in step S404), the process advances to step S411, the end process is executed, and then the process ends.

On the other hand, if the event is not an end instruction (NO in step S404), the flow advances to step S405. In step S405, it is determined whether the event is a transaction generation instruction. If the event is not a transaction generation instruction (step S405)
NO), the process proceeds to step S410, and after executing the process corresponding to the event (referred to as “other process” here),
The process returns to step S402 and the process is repeated.

When the event detected in step S403 is a transaction generation instruction (step S40)
(YES in 5), the process proceeds to step S406. Step S
At 406, a transaction generation process is executed to generate a transaction corresponding to the condition designated by the user. Subsequently, in step S407, it is determined whether or not the transaction has been successfully generated. If the transaction generation is not successful (NO in step S407), the process returns to step S402 and the process is repeated. On the other hand, if the transaction has been successfully generated (YES in step S407), the process advances to step S408.

In step S408, transaction processing according to the user's instruction is executed. Continued, step S
In step 409, the transaction discard processing is executed, and the unnecessary transactions that have already been processed are discarded.
Returning to 402, the above processing is repeated.

Next, an example of the transaction generation screen displayed in the transaction generation processing of step S406 will be described with reference to FIG.

FIG. 5 is a diagram showing an example of the transaction generation screen of the first embodiment. In FIG. 5, reference numeral 51 is a user name input area. Reference numeral 52 is an input area for a password corresponding to the user name. Reference numeral 53 is a combo box for designating the type of database. Reference numeral 54 is an input area for a server name that provides a connection service to the database. Reference numeral 55 is a button for displaying a server name selection dialog which is used when the server name input in the server name input area is unknown. Reference numeral 56 is a database name input area. Reference numeral 57 is a button for displaying a database name selection dialog used when the database name input in the database name input area is unknown.

Reference numeral 58 is a button for instructing transaction generation using the values specified in the above areas. Reference numeral 59 is a button for canceling transaction generation.

Details of the transaction generation processing in step S406 will be described below with reference to FIG. FIG. 6 is a flowchart showing details of the transaction generation processing in step S406 of the first embodiment.

When the transaction generation processing is activated, generation parameter input processing is executed in step S601, the transaction generation processing screen described in FIG. 5 is displayed, and the user is prompted to specify various parameters. Subsequently, in step S602, it is determined whether or not the user has instructed the generation of the transaction in the generation parameter input processing. When the transaction generation is instructed (when the OK button 58 is clicked, YES in step S602), the process proceeds to step S603, DB transaction generation processing is executed, and a transaction corresponding to various parameters designated by the user is generated. . Here, a DB transaction as shown in FIG. 23, which will be described later, is generated, and details thereof will be described later with reference to FIGS. 23 and 24.

Then, in step S604, it is determined whether or not the DB transaction generation processing has succeeded. When the DB transaction generation process is successful (step S6)
If YES, the process ends as "success". On the other hand, if the DB transaction generation process is not successful in step S604 (NO in step S604),
Alternatively, in step S602, when the transaction generation is not instructed (when the cancel button 59 is clicked, NO in step S602), the processing ends as “failure”.

Next, an example of the transaction processing screen displayed in the transaction processing of step S408 will be described with reference to FIG. FIG. 7 is a diagram showing an example of the transaction processing screen of the first embodiment.

In FIG. 7, reference numeral 71 is a menu item for instructing the addition of an object. Reference numeral 72 is a menu item for instructing deletion of an object. Reference numeral 73 is a menu item for instructing to edit an object.

Details of the transaction processing in step S408 will be described below with reference to FIG. FIG. 8 is a flowchart showing details of the transaction processing in step S408 of the first embodiment.

When the transaction process is activated, an initialization process is executed in step S801 to initialize various internal data. Next, in step S802, screen display processing is executed to display the transaction processing screen described in FIG. In a succeeding step S803, an event waiting process is executed to wait for an event corresponding to a user operation.

If the occurrence of an event is detected in step S803, it is determined in step S804 whether the event occurred in response to the operation performed by the user is an end instruction. If the event is an end instruction (YES in step S804), the process advances to step S806 to execute an end process, and then the process ends. On the other hand, if the event is not the end instruction (N in step S804)
O), the process proceeds to step S805, the process corresponding to the designated event (event corresponding process) is executed, the process corresponding to the event is executed, the process returns to step S802, and the process is repeated. It should be noted that in the event handling process in step S805, addition of an object, deletion of an object, or editing of an object is performed by selecting one of the menu items 71 to 73.

When an object is instructed to be added in the event handling process in step S805, an object selection / addition process described below is executed.

First, an example of the additional object selection screen displayed by the object selection / addition process will be described with reference to FIG. FIG. 9 is a diagram illustrating an example of the additional object selection screen according to the first embodiment.

In FIG. 9, reference numeral 91 is a class name input area. Reference numeral 92 is a button for displaying a class information dialog which displays information on the class specified in the class name input area. Reference numeral 93 is a button for displaying a class file selection dialog for selecting / loading a file storing class information used when the class name input in the class name input area is unknown. Reference numeral 94 is a button for generating an object corresponding to the class designated in the class name input area. Reference numeral 95 is a button for displaying an object file selection dialog for selecting and loading an existing object file. Reference numeral 96 is a button for instructing addition of an object generated or loaded by each of the above buttons. 9
Reference numeral 7 is a button for canceling addition of an object.

Next, details of the object selection / addition processing will be described with reference to FIG. FIG. 10 shows the first embodiment.
5 is a flowchart showing details of object selection / addition processing corresponding to an instruction to add an object in the event handling processing of FIG.

When the object selection / addition process is activated, an initialization process is executed in step S1001 to initialize various internal data. Next, step S1002.
Then, the screen display process is executed to display the additional object selection screen described in FIG. Continued at step S1003
Then, the event waiting process is executed to wait for the event corresponding to the user operation. If the occurrence of an event due to a user operation is detected in step S1003, the process proceeds to step S1004.

In step S1004, the event type generated in response to the operation performed by the user is determined, and the process branches to the corresponding process. If the button 94 for generating an object is clicked, it is determined that the event type is an instruction for generating an object, and the process proceeds to step S1006.
In step S1006, an object generation process is executed to generate an object. Then, step S1
Returning to 002, the process is repeated.

In step S1004, the OK button 9
When 6 is clicked, it is determined that the event type is an instruction to add the object generated or loaded above, and the process proceeds to step S1007. Step S100
In 7, the object addition confirmation processing is executed to add the object to the database, and then the change is confirmed. In addition,
The object addition confirmation process will be described later with reference to FIG. As a result, in a succeeding step S1008, it is determined whether or not the change of the object is successful. If the object change is successful (YE in step S1008)
In step S1009, the process proceeds to step S1009, and after the end process is executed, the process ends as “success”. On the other hand, if the change of the object has not succeeded (NO in step S1008), after executing the ending process in step S1010,
The process ends as “failure”.

If the event type is other than the above,
The process proceeds to step S1005, the process corresponding to the other event is executed by the other event handling process, and then the process returns to step S1002 to repeat the process.

Next, the object generation processing in step S1006 will be described.

First, an example of the object edit screen at the time of creating a new object displayed in the object creating process will be described with reference to FIG. FIG. 11 is a diagram showing an example of an object edit screen when creating a new object according to the first embodiment.

In FIG. 11, 111 is an area showing the class name of the object to be edited. An area 112 indicates a list of field names included in the object class. An area 113 indicates the class name of the field selected from the field name list. Reference numeral 114 is an area indicating the attribute of the same field.

Reference numeral 115 is an input area for a value stored in the same field. Reference numeral 116 is a button for displaying an object designation dialog for designating an object that is difficult to directly input in the input area. 117
Is an area showing a list of method names of the object class. Reference numeral 118 is a button for instructing the confirmation of the edited content of the object edited above. A button 119 is used to cancel the editing content of the object.

Details of the object generation processing in step S1006 will be described below with reference to FIGS. 11 and 12. FIG. 12 is a flowchart showing details of the object generation processing in step S1006 of the first embodiment.

When the object generation processing is activated, empty object generation processing is executed in step S1201 to generate a default instance corresponding to the designated class. As a result of empty object generation processing, continued,
In step S1202, it is determined whether the default instance has been successfully created. If the default instance is successfully generated (YES in step S1202)
S), the process proceeds to step S1203, the object edit process is executed, the object edit screen described in FIG. 11 is displayed, and the user's operation is accepted.

As a result of the object edit processing, it is determined in next step S1204 whether or not an instruction to confirm the edit content of the object has been issued. This judgment is OK button 1
This is done based on which of the 18 or the cancel button 119 is clicked. When the confirmation of the edited content of the object is instructed (when the OK button 118 is clicked, YES in step S1204), the processing ends as “success”.

On the other hand, if it is not instructed to confirm the edit content of the object in step S1204 (in this example, the cancel button 119 is clicked, it is determined as NO in step S1204), or step S1202. In the case where the generation of the default instance is not successful (N in step S1202)
O), the processing ends as “failure”.

Next, in the event handling process of step S805, the process when the menu item 73 (FIG. 7) for instructing the editing of the object is selected will be described.

First, an example of the class selection screen displayed when the object selection editing process corresponding to the object editing instruction is activated will be described with reference to FIG. FIG. 13 is a diagram showing an example of the class selection screen of the first embodiment. The class selection screen is displayed in step S1501 described below.

In FIG. 13, 131 is a selection list of class names. Further, 132 is a button for instructing to edit an object corresponding to the class selected above. 133 is a button for canceling the editing of the object.

Further, an object selection / editing process (step S1 to be described later) executed when an object edit is instructed in the event handling process of step S805.
An example of the object edit screen at the time of editing the existing object displayed in 507) will be described with reference to FIG.

FIG. 14 is a diagram showing an example of an object edit screen when editing an existing object according to the first embodiment. In FIG. 14, the value of the field name “name” of 142 is changed from the state at the time of new creation shown in FIG. 11 by the user operation.
As shown by 145, the state is changed from "Japan Taro" to "Japan Taro 1".

Details of the object selection / editing process will be described with reference to FIG. FIG. 15 shows the first embodiment.
6 is a flowchart showing details of the object selection editing process of FIG.

When the object selection / editing process is activated, a class selection process is executed in step S1501.
The class selection screen described with reference to FIG. 13 is displayed to accept the user's selection operation. As a result of the class selection processing, in the next step S1502, it is determined whether or not an instruction to edit the object corresponding to the class has been given. This decision is OK
This is performed according to which one of the button 132 and the cancel button 133 is clicked. When the object editing is not instructed (when the cancel button 133 is clicked, NO in step S1502), the processing ends as “failure”. On the other hand, if the object edit is instructed (YES in step S1502 if the OK button 132 is clicked), step S1
Proceed to 503.

In step S1503, all object acquisition confirmation processing is executed to acquire all objects corresponding to the selected class. Note that step S1503
The all-object acquisition confirmation process will be described later with reference to FIG. As a result of the all object acquisition confirmation process, in the next step S1504, it is determined whether or not the object acquisition has succeeded. If acquisition of the object has not succeeded (NO in step S1504), the processing ends as “failure”. On the other hand, if acquisition of the object is successful (YES in step S1504), step S
Proceed to 1505. Then, in step S1505, initialization is performed so that the processing target is the head of all the acquired objects, and the processing for each object is repeated in the subsequent steps.

First, in step S1506, it is determined whether the processing for all objects to be processed has been completed. If the processes for all the objects to be processed are completed (YES in step S1506), the processing ends as “success”. On the other hand, when the processing for all the objects to be processed is not yet completed (step S1)
(No in 506), the process advances to step S1507.

In step S1507, object edit processing is executed, the object edit screen described with reference to FIG. 14 is displayed, and the user's operation is accepted. As a result of the object edit processing, in the next step S1508, it is determined whether or not an instruction to confirm the edit content of the object has been issued. This determination is made according to which one of the OK button 148 and the cancel button 149 is clicked.
If the confirmation of the edit content of the object has not been instructed (when the cancel button 149 is clicked, NO in step S1508), the process advances to step S1511.
On the other hand, if it is instructed to confirm the edited contents of the object (when the OK button 148 is clicked, step S
(YES in 1508) and the process proceeds to step S1509.

In step S1509, the object update confirmation process is executed, the data in the database is updated with the confirmed edit contents, and the result is confirmed. The object update confirmation process will be described later with reference to FIG. As a result of the object update confirmation process, it is determined in next step S1510 whether or not the data update is successful. If the data update has not succeeded (NO in step S1510), the processing ends as “failure”.
On the other hand, if the data update is successful (step S151)
If YES, the process proceeds to step S1511.

In step S1511, the object to be processed is advanced to the next step, the process returns to step S1506, and the above process is repeated.

Next, the object selecting and deleting process, which is the process when the menu item 72 instructing to delete the object is clicked in the event corresponding process of step S805, will be described.

First, an example of the object reference screen at the time of referring to an existing object, which is displayed in the object selection / deletion process, will be described with reference to FIG. Figure 1
FIG. 6 is a diagram showing an example of an object reference screen when referring to an existing object according to the first embodiment. This reference screen is the same screen as when newly creating in FIG. 11 or when editing in FIG. 14, but the input area for the value stored in the field 165 is in a state in which input is impossible. Are different.

Details of the object selection / deletion process will be described below with reference to FIG. FIG. 17 shows the first embodiment.
8 is a flowchart showing details of the object selection / deletion process.

When the object selection / deletion process is activated, the class selection process of step S1701 is executed, the class selection screen described in FIG. 13 is displayed, and the user's selection operation is accepted. As a result of the class selection processing, in the next step S1702, it is determined whether or not the deletion of the object corresponding to the class is instructed. When the OK button 132 in FIG. 13 is clicked in the object selection and deletion process, it is determined that the object deletion is instructed. Further, when the cancel button 133 is clicked, it is determined that the instruction to delete the object has not been given. If deletion of the object has not been instructed (NO in step S1702), the processing ends as “failure”. On the other hand, if the deletion of the object is instructed (YES in step S1702), the process advances to step S1703.

In step S1703, all object acquisition confirmation processing is executed to acquire all objects corresponding to the selected class. Note that step S170
The all object acquisition confirmation processing of No. 3 will be described later with reference to FIG. As a result of all object acquisition confirmation processing,
Subsequently, in step S1704, it is determined whether the acquisition of the object has succeeded. If acquisition of the object has not succeeded (NO in step S1704), “failure”
The processing ends. On the other hand, if acquisition of the object has succeeded (YES in step S1704), the process advances to step S1705. In step S1705, initialization is performed so that the processing targets are the heads of all the acquired objects, and the processing for each object is repeated in the subsequent steps.

First, in step S1706, it is determined whether processing has been completed for all objects to be processed. If the processes for all the objects to be processed are complete (YES in step S1706), the process ends as “success”. On the other hand, if the processing for all objects to be processed has not been completed (N in step S1706)
O), and proceeds to step S1707.

In step S1707, object reference processing is executed, the object reference screen described with reference to FIG. 16 is displayed, and the user's operation is accepted. As a result of the object reference processing, in the next step S1708, it is determined whether or not the deletion of the object is instructed. This determination is made based on whether the OK button 168 or the cancel button 169 is clicked. When the deletion of the object is not instructed (when the cancel button 169 is clicked, N in step S1708)
O), and proceeds to step S1711. On the other hand, when the deletion of the object is instructed (when the OK button 168 is clicked, YES in step S1708), the process advances to step S1709.

In step S1709, object deletion confirmation processing is executed to delete the data in the database,
Confirm the result. The object deletion confirmation processing will be described later with reference to FIG. As a result of the object deletion confirmation process, it is determined in next step S1710 whether or not the data deletion has succeeded. If the data deletion has not succeeded (NO in step S1710),
The process ends as “failure”. On the other hand, if the data has been successfully deleted (YES in step S1710), the process advances to step S1711. In step S1711, the object to be processed is advanced, the process returns to step S1706, and the process is repeated.

Details of the all object acquisition confirmation processing in steps S1503 and S1703 will be described below with reference to FIG. FIG. 18 is a flowchart showing details of the all object acquisition confirmation processing in steps S1503 and 1703 of the first embodiment.

When the all object acquisition confirmation process is activated, a DB transaction start process is executed in step S1801 to declare the start of a transaction. In a succeeding step S1802, an all object acquisition process is executed to acquire all objects corresponding to the designated class. The all object acquisition process will be described later with reference to FIG. As a result of the all object acquisition process, in the next step S1803, it is determined whether acquisition of all objects has succeeded. If all objects have been successfully acquired (YES in step S1803)
S), and proceeds to step S1804. On the other hand, if acquisition of all objects has not succeeded (step S180)
No in step 3), the process proceeds to step S1805.

In step S1804, the DB transaction confirmation processing is executed, the processing for the database so far is confirmed, and the processing ends as "success". On the other hand, in step S1805, the DB transaction cancellation processing is executed, the processing on the database so far is canceled, and the processing ends as “failure”.

Details of the object addition confirmation process in step S1007 will be described below with reference to FIG. FIG. 19 is a flowchart showing details of the object addition confirmation process of step S1007 of the first embodiment.

When the object addition confirmation process is activated, a DB transaction start process is executed in step S1901 to declare the start of a transaction. In a succeeding step S1902, an object adding process is executed to add the designated object to the database. The object addition process will be described later with reference to FIG. As a result of the object addition processing, in the next step S1903, it is determined whether or not the addition of the object is successful. If the addition of the object has succeeded (YES in step S1903), the process advances to step S1904. On the other hand, if the addition of the object has not succeeded (NO in step S1903), the process advances to step S1905.

In step S1904, the DB transaction confirmation processing is executed, the processing for the database so far is confirmed, and the processing ends as "success". On the other hand, in step S1905, the DB transaction cancellation processing is executed, the processing on the database so far is canceled, and the processing ends as “failure”.

Details of the object update confirmation process in step S1509 will be described below with reference to FIG. FIG. 20 is a flow chart showing details of the object update confirmation process of step S1509 of the first embodiment.

When the object update confirmation process is activated, a DB transaction start process is executed in step S2001 to declare the start of a transaction. In a succeeding step S2002, an object updating process is executed to update the database with the designated object. The object update process will be described later with reference to FIG. As a result of the object update processing, in the next step S2003, it is determined whether or not the object update is successful. If the object has been updated successfully (YES in step S2003), the process advances to step S2004. On the other hand, if the update of the object has not succeeded (NO in step S2003), the process advances to step S2005.

In step S2004, DB transaction confirmation processing is executed, the processing for the database so far is confirmed, and the processing ends as "success". On the other hand, in step S2005, the DB transaction cancellation processing is executed, the processing for the database so far is canceled, and the processing ends as "failure".

Details of the object deletion confirmation process in step S1709 will be described below with reference to FIG. FIG. 21 is a flowchart showing details of the object deletion confirmation process of step S1709 of the first embodiment.

When the object deletion confirmation process is activated, a DB transaction start process is executed in step S2101, and the start of a transaction is declared. In a succeeding step S2102, object deletion processing is executed to delete the designated object from the database. This object deletion processing will be described later with reference to FIG. As a result of the object deletion processing, in the next step S2103, it is determined whether or not the object has been successfully deleted. When the deletion of the object is successful (YES in step S2103), step S21
Go to 04. On the other hand, if the deletion of the object is not successful (NO in step S2103), step S21
Go to 05.

In step S2104, the DB transaction confirmation processing is executed, the processing for the database so far is confirmed, and the processing ends as "success". On the other hand, in step S2105, the DB transaction cancellation processing is executed, the processing for the database so far is canceled, and the processing ends as "failure".

The transaction processing in the information processing apparatus of this embodiment having the above-mentioned configuration and executing the above-mentioned basic processing will be described in detail.

FIG. 22 is a block diagram showing the functional arrangement of the information processing apparatus according to the first embodiment. The DB manager 508 handles a series of transactions (transactions) between one or more application programs A 501 and databases (DB) 506, 507 corresponding to a request from the application program X 502.
3, 504, 505 are generated and discarded.

In FIG. 22, two DBs corresponding to two requests from the application program A 501
Transactions 503 and 504 are generated, and databases 506 and 507 are associated with them, respectively. Further, the DB transaction 505 corresponding to the request from the application program X502 is associated with the same database 507 as the DB transaction 504.

Next, the internal data of the DB transaction will be described with reference to FIG. FIG. 23 is a diagram showing internal data of the DB transaction of the first embodiment. In FIG. 23, the DB transaction is 511.
As shown in, the execution status indicating whether the transaction is being executed, the transaction target database information 512, the undetermined processing list 513 executed during the transaction execution, and the application object that is the processing target after the transaction is generated. And D
The internal data of the object correspondence table 514 that stores the relationship of the B object is configured.

Details of the DB transaction generation processing in step S603 will be described below with reference to FIG. FIG. 24 is a flowchart showing details of the DB transaction generation processing in step S603 of the first embodiment.

When the DB transaction generation process is activated, an initialization process is executed in step S5201 to initialize the internal data of the DB transaction described in FIG. Then, in step S5202, a DB connection process is executed to connect to the database under the specified conditions.
As a result of the DB connection processing, in the next step S5203, it is determined whether or not the database connection is successful. If the connection is not successful (NO in step S5203),
The process ends as “failure”. On the other hand, if the connection is successful (YES in step S5203), step S52
Go to 04. In step S5204, information related to the connection is stored in the internal data of the DB transaction,
The process ends as “success”.

Next, step S1801 and step S in each of all object acquisition confirmation processing of FIG. 18, object addition confirmation processing of FIG. 19, object update confirmation processing of FIG. 20, and object deletion confirmation processing of FIG.
FIG. 25 shows details of the DB transaction start processing of 1901, step S2001, and step S2101.
Will be explained.

FIG. 25 shows step S180 of the first embodiment.
It is a flowchart which shows the detail of the DB transaction start process of 1, step S1901, step S2001, and step S2101.

When the DB transaction start process is activated, it is checked in step S5301 with reference to the execution status of the internal data of the DB transaction described above whether the execution status is "stop". When the execution status is not "stop" (N in step S5301)
O) regards this as "failure" and terminates this processing. On the other hand, if the execution status is “stop” (YES in step S5301), the flow advances to step S5302. Step S53
In 02, the unconfirmed processing list 513 is initialized. In next step S5303, the execution status is changed to "execution in progress", and the processing ends as "success".

Next, step S1804 and step S1 in each of all object acquisition confirmation processing of FIG. 18, object addition confirmation processing of FIG. 19, object update confirmation processing of FIG. 20, and object deletion confirmation processing of FIG.
Details of the DB transaction confirmation processing of 1904, step S2004, and step S2104 will be described with reference to FIG.
Will be explained.

FIG. 26 shows step S180 of the first embodiment.
4 is a flowchart showing details of the DB transaction confirmation processing in step 4, step S1904, step S2004, and step S2104.

When the DB transaction confirmation process is activated, it is checked in step S5401 with reference to the execution status of the internal data of the DB transaction described above whether the execution status is "execution in progress" or not. If the execution status is not "execution in progress" (NO in step S5401), the processing ends as "failure". On the other hand, if the execution status is "execution in progress" (step S540)
If YES, the process proceeds to step S5402. Step S
In 5402, the processing target is set to the head of the unconfirmed processing list 513, and the processing for all the processing targets is repeated in the subsequent steps.

First, in step S5403, it is determined whether the processing for all the processing targets has been completed. When the processing for all the processing targets is not completed (step S540)
(NO in step 3), the process proceeds to step S5404, the process target determination process is executed, the process content performed in the process target database is determined, and the process returns to step S5403. on the other hand,
If the processes for all process targets have been completed (YES in step S5403), the flow advances to step S5405 to change the execution status to “stop”, and ends the process as “success”.

Next, step S1805 and step S in each of all object acquisition confirmation processing of FIG. 18, object addition confirmation processing of FIG. 19, object update confirmation processing of FIG. 20, and object deletion confirmation processing of FIG.
27 for details of the DB transaction cancellation processing of 1905, step S2005, and step S2105.
Will be explained.

FIG. 27 shows step S180 of the first embodiment.
5 is a flowchart showing details of the DB transaction cancellation processing in step 5, step S1905, step S2005, and step S2105.

When the DB transaction cancel processing is activated, it is checked in step S5501 with reference to the execution status of the internal data of the DB transaction described above whether the execution status is "execution in progress" or not. If the execution status is not "execution in progress" (NO in step S5501), the processing ends as "failure". On the other hand, if the execution status is "execution in progress" (step S5501)
YES), and proceeds to step S5502. Step S5
In 502, the execution status is changed to “stop”, and the processing ends as “success”.

Next, the relationship between objects used in the information processing apparatus of the first embodiment will be described with reference to FIG. FIG. 28 is a diagram showing a relationship between objects used in the information processing apparatus of the first embodiment.

In FIG. 28, the database 565 is used in order for the application program A 561 to make the generated or acquired application object 562 permanent data.

At this time, the application program A5
61 does not directly access the database 565, but the database 565 does not access the database 565 as described in the functional configuration of FIG.
Access is made via the DB transaction 563 generated after specifying the connection condition to.

Specifically, the application object 562 generated by the application program A 561 is internally converted into the DB object 566 by the service provided by the DB transaction 563 and then stored in the database 565. at the same time,
The object correspondence table 564 (corresponding to 514 in FIG. 23) that stores the relationship between the application object 562 and the DB object 566 is updated.

On the contrary, the service provided by the DB transaction 563 enables the DB object 566 stored in the database 565 to be internally converted into the application object 562 before being handled. Also in this case, at the same time, the object correspondence table 564 that stores the relationship between the application object 562 and the DB object 566 is updated.

Through the above processing, the application program A561 can acquire / add / update / delete the data stored in the database 565 as the application object 562 without being aware of the structure of the objects in the database 565. Become.

Next, an example of the programming code of the application object used in the information processing apparatus of the first embodiment will be described with reference to FIG.

FIG. 29 is a diagram showing an example of the programming code of the application object of the first embodiment. In FIG. 29, 571 is a package name indicating a group of classes generated from the programming code. 572 is a class name in the package. In fact, the class name of the class generated from the programming code is "co
m.xxxx.ks.KSPerson ”. 573 to 578 represent the definition and the initial value of the field of the class.
There are 6 fields of ALE, $ FEMALE, name, age, sex and contacts. Of these, $ MALE and $ FEMALE are defined as non-rewritable.

As described above, the application object of the information processing apparatus of the first embodiment is an instantiation of the class generated from the programming code, and conversely, by using the service of the application object, Definition information can be acquired.

Next, regarding the list of database objects used in the information processing apparatus of the first embodiment, FIG.
Will be explained. FIG. 30 is a diagram showing a list of database objects according to the first embodiment.

In FIG. 30, 581 is a class name in the database. Reference numeral 582 is an identification ID unique to each database object. Reference numeral 583 is a field name corresponding to each field of the application object. In the figure, it has four fields of name, age, sex, and contacts.

Reference numerals 584 to 587 represent actual values of each data object. Here, the class name in the database does not always match the class name of the application object as shown in FIG.

Further, as shown in FIG. 30, the values of all the fields of the application object are not always stored in the database object. For example,
Of the fields of the application object, the value of the unwritable field ($ MALE, $ FE in this example)
Even if the MALE) is stored in the database object, it is not necessary to have it in the database object because it cannot be written to the application object or is automatically initialized when the default instance of the application object is created. it can.

Details of the all object acquisition process in step S1802 will be described below with reference to FIG.
FIG. 31 is a flowchart showing details of the all object acquisition process in step S1802 of the first embodiment.

When the all object acquisition process is activated,
In step S5901, the execution status of the internal data of the DB transaction is referred to, and it is determined whether the execution status is "execution in progress". When the execution status is not "execution in progress" (N in step S5901)
O), the processing ends as “failure”. On the other hand, if the execution status is "execution in progress" (YES in step S5901), the flow advances to step S5902.

In step S5902, all DB object acquisition processing is executed to acquire all objects in the database corresponding to the specified class. The all DB object acquisition process will be described later with reference to FIG. DB
As a result of the object acquisition processing, the subsequent step S590
At 3, it is determined whether acquisition of all objects has succeeded. If acquisition of all objects has not succeeded (NO in step S5903), the processing ends as “failure”. On the other hand, if acquisition of all objects has succeeded (YES in step S5903), the flow advances to step S5904.

In step S5904, the process target is set to the head of the acquired objects in the database, and the following processes are repeated for all the process target objects in the subsequent steps.

First, in step S5905, it is determined whether the processing has been completed for all objects to be processed. If the processes for all objects to be processed have been completed (YES in step S5905), the process ends as “success”. On the other hand, if the processes for all the objects to be processed are not completed (NO in step S5905), the process advances to step S5906.

In step S5906, object generation processing is executed to generate a default instance of the designated class. This object generation processing will be described later with reference to FIG. Next, step S59.
At 07, an object value setting process is executed, the value of the database object to be processed is referenced, and a value is set in each field of the generated application object. The object value setting process will be described later with reference to FIG. Further, the following step S5
At 908, the combination of the generated application object and the acquired database object is added to the aforementioned object correspondence table.
After that, the process target is advanced to the next object in step S5909, the process returns to step S5905, and the process is repeated.

Details of the object addition processing in step S1902 will be described below with reference to FIG. FIG. 32 is a flowchart showing details of the object addition processing in step S1902 of the first embodiment.

When the object addition process is activated, in step S6001, the execution status of the internal data of the DB transaction is referred to, and it is determined whether the execution status is "execution in progress". When the execution status is not “execution in progress” (NO in step S6001),
The process ends as “failure”. On the other hand, when the execution status is “execution in progress” (YES in step S6001)
S), and proceeds to step S6002.

Next, in step S6002, a DB object generation / addition process is executed to generate and add a database object of a class in the database corresponding to the given application object class. D
The B object generation / addition process will be described later with reference to FIG. In a succeeding step S6003, a DB object value setting process is executed, the value of the given application object is referred to, and a value is set in each field of the generated and added database object. For the DB object value setting process, see FIG.
Will be described later. After that, in step S6004, the information corresponding to the processing is added to the undetermined processing list 513. Subsequently, in step S6005, the combination of the given application object and the generated and added database object is added to the above-mentioned object correspondence table, and the processing ends as “success”.

Details of the object updating process in step S2002 will be described below with reference to FIG. FIG. 33 is a flowchart showing details of the object update processing in step S2002 of the first embodiment.

When the object update process is activated, in step S6101, the execution status of the internal data of the DB transaction is referred to, and it is determined whether the execution status is "execution in progress". When the execution status is not “execution in progress” (NO in step S6101),
Process as "failure". On the other hand, if the execution status is "execution in progress" (YES in step S6101), the flow advances to step S6102.

In step S6102, the aforementioned object correspondence table is referred to and the database object corresponding to the given application object is searched. As a result of the search, in step S6103, it is determined whether the search is successful. If the search has not succeeded (NO in step S6103), the processing ends as “failure”. On the other hand, if the search is successful (step S
If YES in 6103), the process advances to step S6104.

In step S6104, a DB object value setting process is executed, the value of the given application object is referred to, and a value is set in each field of the retrieved database object. Then, in step S6105, information corresponding to the above processing is added to the undetermined processing list 513, and the processing ends as “success”.

Details of the object deleting process in step S2102 will be described below with reference to FIG. FIG. 34 is a flowchart showing details of the object deleting process in step S2102 of the first embodiment.

When the object deleting process is activated, in step S6201, the execution status of the internal data of the DB transaction is referred to, and it is determined whether or not the execution status is "execution in progress". When the execution status is not “execution in progress” (NO in step S6201),
The process ends as “failure”. On the other hand, when the execution status is "execution in progress" (YES in step S6201).
S), and proceeds to step S6202.

Next, in step S6202, the aforementioned object correspondence table 514 is referred to search the database object corresponding to the given application object. As a result of the search, continue, step S6
At 203, it is determined whether the search is successful. If the search has not succeeded (NO in step S6203), the processing ends as “failure”. On the other hand, if the search is successful (YES in step S6203), step S6204.
Proceed to.

In step S6204, DB object deletion processing is executed to delete the searched database object. The DB object deletion process will be described later with reference to FIG. Then, step S62
At 05, information corresponding to the above processing is added to the undetermined processing list 513. Continued at step S6206
Then, the combination of the given application object and the deleted database object is deleted from the above-mentioned object correspondence table 514, and the processing ends as “success”.

Details of the all DB object acquisition processing in step S5902 will be described below with reference to FIG. FIG. 35 shows all DBs in step S5902 of the first embodiment.
It is a flow chart which shows details of object acquisition processing.

When the all DB object acquisition process is activated, a DB class name determination process is executed in step S7001 to determine the database class name in the database corresponding to the application class name of the given application class.

When "." Cannot be used in the class name like the database used in the first embodiment, the result obtained by substituting a character string that can be used in the database such as "___" is used as the database class name. To do. For example,
From the application class name “com.xxxx.ks.KSPerson” to the database class name “com___xxxx___ks___KSPers
on ”is determined.

As a result of the DB class name determination processing, it is determined in subsequent step S7002 whether or not the database class name has been successfully determined. If the determination of the database class name has not succeeded (NO in step S7002),
The process ends as “failure”. On the other hand, when the determination of the database class name is successful (Y in step S7002)
ES), and proceeds to step S7003.

In step S7003, a list of all database objects for output is initialized. Subsequently, in step S7004, the processing target is set at the head of the database object group corresponding to the database class in the database, and then the processing for all the database objects to be processed is repeated in the subsequent steps.

First, in step S7005, it is determined whether the processing has been completed for all database objects to be processed. When all the database objects to be processed have been processed (step S7)
(YES in 005), the processing ends as “success”. On the other hand, if the processes for all the database objects to be processed are not completed (NO in step S7005), the process advances to step S7006.

In step S7006, the database object to be processed is added to the all database object list. Then, in step S7007, the process target is advanced to the next database object, the process returns to step S7005 again, and the process is repeated.

Details of the DB object generation / addition processing in step S6002 will be described below with reference to FIG. FIG. 36 shows the DB of step S6002 of the first embodiment.
It is a flow chart which shows the details of object generation addition processing.

When the DB object generation / addition process is activated, an application class name acquisition process is executed in step S7101, and the application class name of the given application object is acquired. Next, in step S7102, a DB class name determination process is executed to determine the database class name in the database corresponding to the application class name. As a result of the DB class name determination processing, in the following step S7103, it is determined whether the database class name has been successfully determined. If the determination of the database class name has not succeeded (NO in step S7103), the processing ends as “failure”.

On the other hand, if the determination of the database class name is successful (YES in step S7102), step S
Proceed to 7104. In step S7104, a default database object corresponding to the database class is generated and added, and the processing ends as “success”.

Details of the DB object deletion processing in step S6204 will be described below with reference to FIG. FIG. 37 is a flowchart showing details of the DB object deletion processing in step S6204 of the first embodiment.

When the DB object deletion process is activated, a DB class acquisition process is executed in step S7201 to acquire the database class corresponding to the given database object. As a result of the DB class acquisition processing, next, in step S7202, it is determined whether the acquisition of the database class has succeeded. If acquisition of the database class has not succeeded (NO in step S7202), the processing ends as “failure”.

On the other hand, if acquisition of the database class has succeeded (YES in step S7202), step S7.
Proceed to 203. In step S7203, the given database object is deleted using the service of the database class, and the processing ends as “success”.

Details of the DB object value setting process in steps S5907 and S6003 in each of the object adding process of FIG. 31 and the object updating process of FIG. 32 will be described below with reference to FIG. FIG. 38 is a flowchart showing details of the DB object value setting process in steps S5907 and S6003 of the first embodiment.

When the DB object value set process is activated, all writable field name acquisition process is executed in step S7301, and each writable field name is referenced by referring to each field definition of the given application object. get. The all writable field name acquisition process will be described later with reference to FIG. As a result of the all writable field name acquisition process, in the following step S7302, it is determined whether the field name acquisition is successful. If acquisition of the field name has not succeeded (NO in step S7302), the processing ends as “failure”. On the other hand, if acquisition of the field name has succeeded (YES in step S7302), step S
Proceed to 7303.

Next, in step S7303, the process target is set to the head of the above-mentioned acquired all writable field name list, and then the processes for all the process target fields are repeated in the subsequent steps.

In next step S7304, it is determined whether or not the processing for all fields to be processed is completed. If the processing for all fields to be processed is completed (YES in step S7304), the processing ends as “success”. On the other hand, if the processing has not been completed for all fields to be processed (N in step S7304).
O), and proceeds to step S7305.

Next, in step S7305, it is determined whether the field to be processed is an array. If the field is not an array (NO in step S7305), the flow advances to step S7306. In step S7306, field value acquisition processing is executed to acquire a value corresponding to the field name of the processing target of the given application object. In subsequent step S7307, DB field value setting processing is executed and stored in the corresponding field of the database object. Then, step S730
In step 8, the field to be processed is advanced to the next field, the process returns to step S7304, and the process is repeated.

On the other hand, if the field to be processed is an array in step S7305 (Y in step S7305).
ES), and proceeds to step S7309. Step S730
At 9, the array field value acquisition process is executed to acquire the value corresponding to the field name to be processed by the given application object. Continued in Step S7310
Then, the DB array field value setting process is executed and stored in the corresponding field of the database object. Then, in step S7308, the field to be processed is advanced to the next, the process returns to step S7304, and the process is repeated.

Details of the object generation processing in step S5906 will be described below with reference to FIG. FIG. 39 is a flowchart showing details of the object generation processing in step S5906 of the first embodiment.

When the object generation process is activated, a DB class name acquisition process is executed in step S7401.
Gets the database class name of the given database object. Next, in step S7402, application class name determination processing is executed to determine the application class name corresponding to the database class name.

As a result of the application class name determination processing, in step S7403, it is determined whether the application class name has been successfully determined. If the determination of the application class name has not succeeded (NO in step S7403), the processing ends as “failure”.
On the other hand, if the determination of the application class name has succeeded (YES in step S7403), step S7404.
Proceed to. In step S7404, a default application object corresponding to the application class is generated, and the processing ends as “success”.

Details of the object value setting process in step S5907 will be described below with reference to FIG. FIG. 40 is a flow chart showing details of the object value setting process of step S5907 of the first embodiment.

When the object value setting process is activated, all writable field name acquisition process is executed in step S7501, and each writable field name is acquired by referring to each field definition of the given application object. To do. The all writable field name acquisition process will be described later with reference to FIG. As a result of the all writable field name acquisition process, in the following step S7502, it is determined whether the field name acquisition has succeeded. If acquisition of the field name has not succeeded (NO in step S7502), the processing ends as “failure”. On the other hand, if acquisition of the field name has succeeded (YES in step S7502), step S
Continue to 7503.

In step S7503, the field name to be processed is set at the head of the list of all the writable field names acquired as described above, and the processes for all fields to be processed are repeated in the subsequent steps.

First, in step S7504, it is determined whether the processing has been completed for all fields to be processed. If the processing for all fields to be processed is completed (YES in step S7504), the processing ends as “success”. On the other hand, if the processing has not been completed for all fields to be processed (N in step S7504).
O), and proceeds to step S7505.

Next, in step S7505, it is determined whether the field to be processed is an array. If the field is not an array (NO in step S7505), the flow advances to step S7506. In step S7506, a DB field value acquisition process is executed to acquire a value corresponding to the field name of the processing target of the given database object. In next step S7507, a field value setting process is executed and stored in the corresponding field of the application object. Step S7508
Then, the field to be processed is advanced to the next step, and step S is performed again.
Returning to 7504, the process is repeated.

If it is determined in step S7505 that the field is an array (YES in step S7505), the flow advances to step S7509. In step S7509, the DB
Executes array field value acquisition processing and acquires the value corresponding to the field name of the processing target of the given database object. In a succeeding step S7510, an array field value setting process is executed and stored in the corresponding field of the application object. Step S7
In 508, the field to be processed is advanced to the next step, the process returns to step S7504 and the process is repeated.

Next, the details of the all writable field name acquisition process of steps 7301 and S7501 in the DB object value setting process of FIG. 38 and the object value setting process of FIG. 40 will be described with reference to FIG.
Will be explained. FIG. 41 shows step S7 of the first embodiment.
301 is a flowchart showing details of all writable field name acquisition processing in step S7501.

When the all writable field name acquisition process is activated, the all field information acquisition process is executed in step S7601 to acquire each field information of the given application object. As a result of the all-field information acquisition processing, it is determined in subsequent step S7602 whether or not the field information has been successfully acquired. If acquisition of field information has not succeeded (step S76)
No in 02), the processing ends as “failure”. on the other hand,
When acquisition of the field information is successful (step S76)
If YES in 02), the process advances to step S7603.

[0173] In step S7603, a list of all writable field names for output is initialized. Subsequently, in step S7604, the process target is set to the head of the above-mentioned acquired all field information, and then the process for all process targets is repeated in the subsequent steps.

First, in step S7605, it is determined whether the processing for all field information to be processed has been completed. If the processing has been completed for all the field information to be processed (YES in step S7605),
The process ends as “success”. On the other hand, if the processing for all field information to be processed has not been completed (NO in step S7605), the flow advances to step S7606.

[0175] In step S7606, it is determined whether the field attribute of the field information is externally referable (Public). If the field attribute is not externally referable (NO in step S7606), step S7609.
Proceed to. On the other hand, if the field attribute can be externally referenced (YES in step S7606), step s7607.
Proceed to.

In step S7607, it is determined whether the field attribute of the field information is unwritable (Final). If the field attribute is not writable (YES in step S7607), step S7
Proceed to 609. On the other hand, if the field attribute is not writable (NO in step S7607), step S
Proceed to 7608.

In step S7608, the field name to be processed is added to the all writable field name list. That is, the field attribute of the field information can be externally referenced (Public) and cannot be written (Final)
If not, the field name is added to the list in step S7608. Then, step S7609
Then, the field information to be processed is advanced to the next step, the process returns to step S7605 and the process is repeated.

As described above, according to the first embodiment, with respect to a database that stores permanent data,
The definition information of the application object referred to by the application program is acquired, and the database is operated using the application object and the acquired application object definition information.

As a result, the database can be used for handling persistent data without learning the coding procedure and complicated know-how peculiar to the database module, and the developer can concentrate on the development of original business logic. Therefore, the development efficiency can be dramatically improved.

<Second Embodiment> Next, a second embodiment will be described.

FIG. 42 is a diagram showing a hierarchically structured database operating means of the information processing apparatus of the second embodiment. The database operation means according to the second embodiment includes an application IF (interface) layer 8001 and a database I.
It is composed of three layers of an F (interface) layer 8002 and an individual database operation implementation 8003.

The application IF layer 8001 serves as a bridge for absorbing differences in various data structures used in the application program and the database and differences in methods. Specifically, the application object and the database object are converted into each other, and the database method is wrapped in a form required by the application program.

The database IF layer 8002 provides an upper class or interface for various database operations, and at the same time provides methods common to various databases. This makes it possible to implement a common method for all databases and eliminate the need to individually implement common processing that does not depend on individual databases.

Also, individual database operation implementation 8003
Then, it is possible to implement various databases individually simply by extending the upper class or interface provided by the database IF operation.

By making the database operation means a hierarchical structure as described above, it becomes possible for the application developer to use different databases without using individual methods. Also, the individual database provider can incorporate the provided database without modifying the existing application. Furthermore, for application developers who have different requirements, it is possible to realize more specialized functions by developing a dedicated application IF layer.

Next, the hierarchical DB transaction structure of the second embodiment will be described with reference to FIG. FIG. 43 is a diagram showing a hierarchical DB transaction structure according to the second embodiment.

DB manager 8105 of the second embodiment
Is a DB transaction 81 that handles a series of transactions with the database 8104 in response to a request from the application program A 8101.
02 is generated and discarded. Here, the DB transaction 8102 is an application interface layer that exchanges with the application program A 8101,
Implementation DB transaction 810 of each database
It consists of a database interface layer that depends on 3.

Next, the internal data of the hierarchical DB transaction will be described with reference to FIG. FIG. 44 is a diagram showing internal data of a hierarchical DB transaction according to the second embodiment.

As indicated by reference numeral 8201, the hierarchical DB transaction includes information 8202 on the actually installed DB transaction and an object correspondence table 8205 for storing the relationship between the application object and the DB object which are the processing target after the transaction is generated. Holds internal data.

Also, information 8 of the mounting DB transaction
202 has an execution status indicating whether or not a transaction is being executed, information 8203 of the database that is the target of the transaction, and an unconfirmed processing list 8204 executed during the execution of the transaction.

Next, the transaction generation screen in the state where the database type is selected in the transaction generation screen shown in FIG. 5 will be described with reference to FIG. FIG. 45 is a diagram showing an example of a transaction generation screen when the type of database of the second embodiment is selected. By clicking 53, a combo box 8304 for designating a database type is displayed, and an arbitrary database type can be selected.

Next, with reference to FIG. 46, a transaction generation screen for inputting a server name in the transaction generation screen shown in FIG. 5 will be described. Figure 4
6 is a diagram showing an example of a transaction generation screen when the server name of the second embodiment is input. Reference numeral 54 is an input area for a server name that provides a connection service to the database, and an arbitrary server name can be designated or nothing can be designated.

Next, step S60 in the second embodiment.
Details of the DB transaction generation process of No. 3 will be described with reference to FIG. 47. FIG. 47 is a flow chart showing details of the DB transaction generation processing of the second embodiment.

When the DB transaction generation process is started, the initialization process of step S8501 is executed, and the process shown in FIG.
The internal data of the hierarchical DB transaction described in 4 is initialized. In next step S8502, it is determined whether the server name specified on the transaction generation screen described in FIG. 46 is valid. If the server name is valid (YES in step S8502), step S85.
In step 03, the remote database manager generation process is executed to generate a database manager for connecting to the server specified by the server name. On the other hand, if the server name is not valid (NO in step S8502),
In step S8504, the corresponding database manager generation process is executed to generate the database manager of the database designated on the transaction generation screen described with reference to FIG.

In next step S8505, the implemented DB transaction initialization processing provided by the generated database manager is executed, and implementation D described in FIG.
Initializes the internal data of the B transaction.

In step S8506, the DB connection process provided by the database manager generated above is executed to connect to the database under the specified conditions. As a result of the DB connection processing, next, step S8507
Then, it is determined whether or not the database connection is successful.
If the database connection is not successful (step S
If NO in 8507), the processing ends as “failure”. On the other hand, if the database connection is successful (step S8)
If YES, the process proceeds to step S8508. In step S8508, information related to the connection is stored in the internal data of the mounting DB transaction, and the processing ends as “success”.

Next, the relationship between packages, which is a group of some purposes described in the hierarchical DB transaction structure, will be described with reference to FIG. FIG. 48 is a diagram showing an example of a relationship between packages, which is a set of some purposes of the hierarchical DB transaction structure of the second embodiment.

In FIG. 48, 8601 and 8612 are shown.
Is a group of systems, devices, processes, etc. on which the second embodiment operates, and objects can be exchanged with each other using a protocol such as RMI. Here, the application program 8602 is the application IF layer 8 existing on the same device 8601.
The database 8611 can be accessed by the package com.xxxx.cdbm8605 in which 603 is mounted.

Also, the application IF layer 8603
Is the package com.xxx of the database IF layer 8604
x.cdbm.mng8606 and com.xxxx.cdbm.mng.admin86
It is implemented using 07.

However, the individual database-specific implementation is as follows:
Package com.xxxx.cdbm.core8 that extends the interface or class of the database IF layer 8604.
608 and com.xxxx.cdbm.rmi8609.
Also, the package com.xxxx.cdbm.file8610 is a database 861 used in the package 8608.
The physical structure of No. 1 is hidden.

Further, to access the database existing in a different device, it is realized by using the package com.xxxx.cdbm.svr8613 of another device via the protocol such as RMI mounted in the package 8609. It should be noted that although the package 8613 and the following packages can be mounted freely, the database I is similar to the above-described configuration in FIG.
Package of F layer 8614 com.xxxx.cdbm.mng8615
And com.xxxx.cdbm.mng.admin8616.

Next, the relationship between the classes described in the hierarchical DB transaction structure will be described with reference to FIG. FIG. 49 is a diagram showing an example of a relationship between classes of the hierarchical DB transaction structure according to the second embodiment.

In FIG. 49, 8701 and 8708
Is a group of systems, devices, processes, etc. on which the second embodiment operates, and objects can be exchanged with each other using a protocol such as RMI.

Here, the application is the DB manager class CDBM existing on the same device 8701.
DB transaction class CDBMTr using 8702
Can generate ansaction 8703 and access the database.

DB transaction class CDBMTransact
Inside ion8703, the implementation DB transaction class CDBTransaction8 corresponding to the specified database
Have 704.

Implementation DB transaction class CDBTrans
The action 8704 has a database class CDBDatabase8705 corresponding to the designated database. Further, the database class CDBDatabase8705 has a database definition class CDBClass8706 corresponding to the definition of stored data. Within the database class CDBClass8706, the database object class CDBObj corresponding to the stored data is stored.
It has an ect8707.

Next, the basic class hierarchy described in the hierarchical DB transaction structure will be described with reference to FIG. FIG. 50 is a diagram showing an example of the basic class hierarchy of the hierarchical DB transaction structure of the second embodiment.

In FIG. 50, the application 880 is used.
1 is the application IF layer com.xxxx.cdbm8802
Access the database using the service provided by. In addition, application IF layer com.xxxx.cdbm
Each 8802 class is a database IF layer com.xxxx.c
It is processed using the service provided by dbm.mng and com.xxxx.cdbm.mng.admin8803.

Next, of the hierarchical DB transaction structure, the hierarchical DB transaction structure when the database exists on the same device as the application program will be described with reference to FIG. FIG. 51 is a diagram showing an example of a hierarchical transaction structure when a database exists on the same device as the application program of the second embodiment.

DB manager 8905 of the second embodiment
Is a DB transaction 890 that handles a series of transactions with the database 8904 corresponding to a request from the application program A8901.
Generate and discard 2. Here, DB transaction 8
Reference numeral 902 denotes an application interface layer that interacts with the application program A8901, and a local implementation DB of a database existing in the same device.
It consists of a database interface layer that depends on transaction 8903.

Next, FIG. 52 shows the basic class hierarchy when the basic class hierarchy is extended to the local database.
Will be explained. FIG. 52 is a diagram showing an example of the basic class hierarchy when extended to the local database of the second embodiment.

In FIG. 52, the application 900
1 is the application IF layer com.xxxx.cdbm9002
Access the database using the service provided by. In addition, application IF layer com.xxxx.cdbm
Each class of 9002 is a database IF layer com.xxxx.cdbm.mng and com.xxxx.cdbm.mng.admin described in FIG.
Processed using the service provided by. However, its implementation is the core database com.xxxx.cdb as shown in the figure.
It is provided by m.core9003. That is, Cor
e database com.xxxx.cdbm.core9003 is shown in FIG.
Database IF layer com.xxxx.cdbm.mng and c described in
It is implemented by extending the interface and class provided by om.xxxx.cdbm.mng.admin.

Here, the core database com.xxxx.c
The dbm.core9003 is implemented using a file IF layer com.xxxx.cdbm.file9004 that hides the physical structure of the database.

Next, of the hierarchical DB transaction structure, the hierarchical DB transaction structure in the case where the database exists on a device different from the application program will be described with reference to FIG.

FIG. 53 is a diagram showing an example of a hierarchical DB transaction structure when a database exists on a device different from the application program of the second embodiment. The DB manager 9104 of the second embodiment creates / discards a DB transaction 9102 that handles a series of transactions (transactions) with the database 9106 corresponding to the request from the application program A9101.

Here, the DB transaction 9102
Is composed of an application interface layer that interacts with the application program A 9101 and a database interface layer that depends on a remote implementation DB transaction 9103 with a database that exists in a different device 9105.

Next, FIG. 54 shows the basic class hierarchy when the basic class hierarchy is extended to a remote database.
Will be explained. FIG. 54 is a diagram showing an example of a basic class hierarchy when extended to the remote database of the second embodiment.

In FIG. 54, the application 920 is displayed.
1 is the application IF layer com.xxxx.cdbm9202
Access the database using the service provided by.

Application IF layer com.xxxx.c
Each class of the dbm9202 is a database IF layer com.xxxx.cdbm.mng and com.xxxx.cdbm.mng.a described in FIG.
It is processed using the service provided by dmin. However,
Its implementation is remote database com.xxx as shown in the figure.
Supplied by x.cdbm.rmi9203. That is, the remote database com.xxxx.cdbm.rmi9203 is the database IF layer com.xxxx.cdbm.mng described in FIG.
And it is implemented in the form that extends the interface and class provided by com.xxxx.cdbm.mng.admin.

Here, the remote database com.xxxx.c
dbm.rmi9203 is implemented using a server database com.xxxx.cdbm.svr9204 that provides a remote interface for accessing databases on different devices.

Next, of the hierarchical DB transaction structure, the hierarchical DB transaction structure for providing a database service to application programs on different devices will be described with reference to FIG. FIG. 55 is a diagram showing an example of a hierarchical DB transaction structure in the case of providing a database service to application programs on different devices according to the second embodiment.

DB manager 9304 of the second embodiment
Is a DB transaction 93 that handles a series of transactions with the database 9307 corresponding to a request from the application program A9301.
02 is generated and discarded.

Here, the DB transaction 9302
Is composed of an application interface layer that interacts with the application program A9301, and a remote database interface layer that depends on a remote implementation DB transaction 9303 with a database 9307 that exists in a different device 9308.

On the other hand, D which provides the database service
The B manager 9308 provides a server mounted DB transaction 9305 in which the database IF layer depending on the mounted DB transaction 9306 of the database 9307 is extended so that it can be used from different devices.

As described above, from the application side, the remote interface with the database existing in a different device is hidden by the remote mounting DB transaction 9303, and from the database side, the local service is stored in the server mounting DB transaction 9305. Can be extended to be used by different devices.

Next, the database IF of the basic class hierarchy
The basic class hierarchy when the remote interface is extended so that the layers can be used by different devices will be described with reference to FIG.

FIG. 56 is a diagram showing an example of a basic class hierarchy when the remote interface is extended so that the database IF layer of the second embodiment can be used by different devices. In FIG. 56, the database IF layer 94
The remote interface is extended by the server database 9401 so that 02 can be accessed from different devices.

As described above, according to the second embodiment,
A database that stores persistent data, an application interface that interprets and processes operations by application programs, a database interface that interprets and processes common database operations, and an individual database that performs individual database processing Thus, the difference in the type of database and the difference in whether it exists locally or on the server are absorbed without generating extra overhead for the local database. This allows the database to be used to work with persistent data without having to be familiar with the individual interfaces, allowing developers to focus on developing their own business logic, which dramatically improves development efficiency. There is an effect that improvement is realized.

<Third Embodiment> FIG. 57 is a diagram showing a flow of notification information according to a change in a database according to the third embodiment.

In FIG. 57, a DB transaction A10005 is generated by using the DB manager 10004 existing on the same device 10001 as the application program 10002. Similarly, the application program 10003 generates a DB transaction X10006.

Here, the DB transaction A1000
The notification information is notified to the DB manager 10004 according to the change caused by the processing performed in step 5. The DB manager 10004 notifies the notified notification information to the managed DB transaction A10005 and DB transaction X10006. The DB transaction A10005 that has received the above notification notifies the application program 10002, and similarly the DB transaction X10006 indicates the application program X1.
Notify 0003.

[0232] According to the above flow, the application program which has received the notification information executes appropriate processing such as redisplay of the database information according to each judgment.

Next, the hierarchical DB transaction structure of the third embodiment will be described with reference to FIG. The hierarchical DB transaction structure of the third embodiment is the same as that of the second embodiment.
Introduces the concept of implementation DB transaction management list to the hierarchical DB transaction structure of.

FIG. 58 is a diagram showing the hierarchical DB transaction structure of the information processing apparatus of the third embodiment.

DB manager 10110 of the third embodiment
Is a DB transaction 1 that handles a series of transactions with the database 10105 corresponding to a request from the application program A 10101.
0103 is generated and discarded. Here, the DB transaction 10103 is the application program A10.
101 and an implementation DB transaction A10104 which is a database interface layer depending on the implementation of each database. Similarly, a DB transaction 10106 and a mounted DB transaction X10107 that handle a series of transactions with the database 10108 corresponding to a request from the application program X10102 are generated.

The implementation DB transaction group thus generated is the implementation DB transaction management list 1010.
9 stored and managed.

Next, the internal data of the hierarchical DB transaction will be described with reference to FIG. FIG. 59 is a diagram showing internal data of a hierarchical DB transaction according to the third embodiment.

As indicated by reference numeral 10201, the hierarchical DB transaction is information 10202 of the actually installed DB transaction, the application object which is the processing target after the transaction is generated, and D.
It has internal data of the object correspondence table 10206 which stores the relation of B objects.

Also, information 1 of the mounting DB transaction
Reference numeral 0202 denotes an execution status indicating whether or not a transaction is being executed, information 10203 of the database that is the target of the transaction, an unconfirmed processing list 10204 executed during the execution of the transaction, and a notification destination of the database. It has a DB listener that holds information (for example, the application program 10205) and an update status that holds the change status of the database.

Details of the transaction discarding process of the third embodiment in step S409 will be described below with reference to FIG.
It will be described using 0.

FIG. 60 is a flow chart showing details of the transaction discard processing of the third embodiment executed in step S409.

When the transaction discarding process is activated, the DB transaction discarding process is executed in step S10301 to discard the corresponding DB transaction. As a result of the DB transaction discarding process, in the next step S10302, it is determined whether the DB transaction has been discarded successfully. If the discard of the DB transaction is successful (YES in step S10302),
The process ends as “success”. On the other hand, if the discard of the DB transaction has not succeeded (step S103)
No in 02), the processing ends as “failure”.

Details of the DB transaction generation processing of the third embodiment executed in step S603 will be described below with reference to FIG. FIG. 61 shows the third embodiment.
5 is a flowchart showing details of the DB transaction generation process of FIG.

When the DB transaction generation process is activated, initialization process is executed in step S10401,
The internal data of the hierarchical DB transaction described in FIG. 59 is initialized. Subsequently, in step S10402, FIG.
It is determined whether the server name specified on the transaction generation screen described in 6 is valid. If the server name is valid (YES in step S10402), the flow advances to step S10403 to execute remote database manager generation processing, and generate a database manager for connecting to the server specified by the server name.
On the other hand, if the server name is not valid (step S1040)
(NO in 2), the flow advances to step S10404 to execute the corresponding database manager generation processing, and generate the database manager of the database specified on the transaction generation screen described with reference to FIG.

In next step S10405, the implemented DB transaction initialization processing provided by the generated database manager is executed to initialize the internal data of the implemented DB transaction described in FIG.

[0246] In subsequent step S10406, the DB connection processing provided by the database manager generated above is executed to connect to the database under the specified conditions. As a result of the DB connection processing, next, step S10407
Then, it is determined whether or not the database connection is successful.
If the database connection is not successful (step S
If NO in 10407), the processing ends as “failure”.
On the other hand, if the database connection is successful (step S
(YES in 10407), and proceeds to step S10408.

In step S10408, information related to the connection is stored in the internal data of the mounting DB transaction. Next, in step S10409, the given database change notification destination is stored in the DB listener. next,
In step S10410, the generated mounting DB transaction is added to the mounting DB transaction management list, and the processing ends as “success”.

Next, the DB transaction discard processing in step S10301 will be described with reference to FIG. FIG. 62 shows the DB of step S10301 of the third embodiment.
It is a flow chart which shows details of transaction disposal processing.

When the DB transaction discarding process is activated, the process target is set to the head of the mounted DB transaction management list in step S10501, and then the processes for all the mounted DB transactions to be processed are repeated in the subsequent steps.

[0250] In step S10502, it is determined whether or not the processing for all mounted DB transactions to be processed has been completed. When the processing for all the mounted DB transactions to be processed is completed (step S105)
No in 02), the processing ends as “failure”. on the other hand,
If the processes for all the implemented DB transactions to be processed have not been completed (YES in step S10502),
Proceeds to step S10503.

Next, in step S10503, it is determined whether or not the mounting DB transaction to be processed matches the mounting DB transaction to be discarded. When the implementation DB transaction to be processed and the implementation DB transaction to be discarded match (step S105)
(YES in 03), the process advances to step S10505, the processing target mounted DB transaction is deleted from the mounted DB transaction management list, and then the processing ends as “success”.

On the other hand, in step S10503, the implementation DB transaction to be processed and the implementation D to be discarded are
If the B transactions do not match (YES in step S10503), the process advances to step S10504 to proceed to the implementation DB transaction to be processed,
The procedure returns to step S10502 again, and the above processing is repeated.

Next, step S60 in the third embodiment.
For details of the DB object generation addition process of 02,
This will be described with reference to FIG. 63. FIG. 63 is a flowchart showing details of the DB object generation / addition processing in step S6002 according to the third embodiment.

When the DB object generation / addition process is activated, an application class name acquisition process is executed in step S10601 to acquire the application class name of the given application object. Next, in step S10602, a DB class name determination process is executed to determine the database class name in the database corresponding to the application class name.

As a result of the DB class name determination processing, it is determined in next step S10603 whether the database class name has been successfully determined. If the determination of the database class name has succeeded (NO in step S10603), the processing ends as “failure”.

On the other hand, if the database class name has been successfully determined (YES in step S10603), the flow advances to step S10604. Next, in step S10604,
Create and add a default database object corresponding to the database class. Next, step S1
In 0605, an “addition” flag indicating that data has been added is added to the update status, and the processing ends as “success”.

Next, step S62 in the third embodiment.
Details of the DB object deletion processing of 04 are shown in FIG.
4 will be described. FIG. 64 is a flowchart showing details of the DB object deletion processing according to the third embodiment.

When the DB object deletion process is activated, a DB class acquisition process is executed in step S10701 to acquire the database class corresponding to the given database object.

As a result of the DB class acquisition processing, next, in step S10702, it is determined whether the acquisition of the database class has succeeded. If acquisition of the database class has not succeeded (NO in step S10702), the processing ends as “failure”. On the other hand, if acquisition of the database class has succeeded (YES in step S10702).
S), and proceeds to step S10703.

In step S10703, the given database object is deleted by using the service of the database class. Next, step S10704.
Then, a "deletion" flag indicating that the data has been deleted is added to the update status, and the processing ends as "success".

Next, the details of the DB object value setting process according to the third embodiment of steps S5907 and S6003 in the object adding process of FIG. 31 and the object updating process of FIG. 32 will be described with reference to FIG.
This will be described using 5.

FIG. 65 shows step S590 of the third embodiment.
7 is a flowchart showing details of the DB object value setting process in step S6003.

When the DB object value set process is activated, all writable field name acquisition process is executed in step S10801, and each writable field name is referenced by referring to each field definition of the given application object. get.

As a result of the all writable field name acquisition process, in a succeeding step S10802, it is determined whether or not the field name has been successfully acquired. If the acquisition of the field name has not succeeded (NO in step S10802),
The process ends as “failure”. On the other hand, if acquisition of the field name is successful (YES in step S10802).
S), and proceeds to step S10803. Step S108
In 03, after setting the processing target to the head of the above-mentioned acquired all writable field name list, the processing for all fields to be processed is repeated from the next step.

[0265] In step S10804, it is determined whether the processing has been completed for all fields to be processed. If the processing for all fields to be processed is complete (YES in step S10804), step S
In step 10811, an “update” flag indicating that the data has been updated is added to the update status, and the processing ends as “success”. On the other hand, if the processing has not been completed for all fields to be processed (N in step S10804).
O), and proceeds to step S10805.

[0266] In step S10805, it is determined whether the field to be processed is an array. If the field is not an array (NO in step S10805), the flow advances to step S10806. In step S10806, a field value acquisition process is executed to acquire a value corresponding to the field name of the processing target of the given application object. In subsequent step S10807, DB field value setting processing is executed and stored in the corresponding field of the database object. And step S1
In 0808, the field to be processed is advanced to the next field, the process returns to step S10804, and the process is repeated.

On the other hand, in step S10805, if the field to be processed is an array (step S10805).
YES), and proceeds to step S10809. Step S
In 10809, the array field value acquisition process is executed to acquire the value corresponding to the field name of the processing object of the given application object. Continued, step S
At 10810, DB array field value set processing is performed and stored in the corresponding field of the database object. Then, in step S10808, the field to be processed is advanced, the process returns to step S10804, and the process is repeated.

Next, step S1804 and step S in each of all object acquisition confirmation processing of FIG. 18, object addition confirmation processing of FIG. 19, object update confirmation processing of FIG. 20, and object deletion confirmation processing of FIG.
Details of the DB transaction confirmation processing according to the third embodiment executed in 1904, step S2004, and step S2104 will be described with reference to FIG. 66.

FIG. 66 shows step S180 of the third embodiment.
4 is a flowchart showing details of the DB transaction confirmation processing in step 4, step S1904, step S2004, and step S2104.

When the DB transaction confirmation process is activated, it is checked in step S10901 with reference to the execution status of the internal data of the hierarchical DB transaction described in FIG. 59 whether the execution status is "execution in progress". . If the execution status is not "execution in progress" (NO in step S10901), the processing ends as "failure". On the other hand, if the execution status is “execution in progress” (YES in step S10901), step S109
Go to 02. In step S10902, the process target is set to the head of the unconfirmed process list, and then the process for all process targets is repeated in the subsequent steps.

It is checked in step S10903 if processing has been completed for all processing targets. When the process for the process target is not completed (step S1090)
(NO in 3), the process proceeds to step S10904, the process target confirmation process is executed, the process contents performed in the target database are confirmed, and the process returns to step S10903.

On the other hand, in step S10903, when the process for the process target is completed (step S10903).
YES), and proceeds to step S10905. Step S
In 10905, it is determined whether or not it has been updated with reference to the update status. If updated (step S1090)
If YES, the process proceeds to step S10907. On the other hand, if it has not been updated (NO in step S10905),
The process advances to step S10906. Step S10906
Then, the update information generation notification process is executed, and the update information is notified to the corresponding database.

Thereafter, in the following step S10907,
Change the execution status to "stopped". Next, in step S10908, the update status is initialized and "successful"
The processing ends.

Details of the update information generation notification process in step S10906 will be described below with reference to FIG.
FIG. 67 is a flowchart showing details of the update information generation notification process of step S10906 of the third embodiment.

When the update information generation notification process is activated, the update status of the internal data of the hierarchical DB transaction described in FIG. 59 is referred to in step S11001,
It is determined whether the update status is "addition". When the update status is not "addition" (step S110)
(NO at 01), the process proceeds to step S11004. On the other hand, when the update status is “addition” (step S110)
If YES at 01), the process proceeds to step S11002. In step S11002, additional notification information generation processing is executed,
Generate additional notification information to be notified. Then, in step S11003, the DBM additional notification information notification processing is executed, and the generated additional notification information is notified to the corresponding database.

Next, in step S11004, the update status of the internal data of the DB transaction described with reference to FIG. 59 is referred to, and it is determined whether the update status is "delete". If the update status is not “delete” (NO in step S11004), step S1100
Proceed to 7. On the other hand, if the update status is “delete” (YES in step S11004), step S110
Go to 05. In step S11005, deletion notification information generation processing is executed to generate deletion notification information to be notified. Then, in step S11006, DBM deletion notification information notification processing is executed, and the generated deletion notification information is notified to the corresponding database.

In step S11007, the update status of the internal data of the DB transaction described with reference to FIG. 59 is referred to, and it is determined whether the update status is "update". If the update status is not "update" (NO in step S11007), the process ends. On the other hand, if the update status is “update” (step S
(YES in 11007), and the process proceeds to step S11008.
In step S11008, update notification information generation processing is executed to generate update notification information to be notified. Then, in step S11009, DBM update notification information notification processing is executed, and the generated update notification information is notified to the corresponding database.

Next, the notification information generated in the update notification information generation processing in step S11008 will be described with reference to FIG. FIG. 68 shows step S110 of the third embodiment.
It is a figure which shows an example of the notification information produced | generated by the update notification information production | generation process of 08. The notification information 11101 has a target database 11102 indicating a database corresponding to the notification type indicating the type of notification information. 69 to 7 described later
In the process of No. 1, steps S11201 and S113
01, empty notification information (notification information framework) is generated in S11401, and thereafter, values are stored in the “notification type” and the “target database”.

Details of the additional notification information generation processing in step S11002 will be described below with reference to FIG.
FIG. 69 is a flowchart showing details of the additional notification information generation processing in step S11002 of the third embodiment.

When the additional notification information generating process is activated, the above-mentioned notification information is generated in step S11201. In a succeeding step S11202, an "addition" flag indicating that data has been added to the database is set in the notification type of the notification information. Sequential step S11203
Then, the information of the target database of the transaction itself is set in the target database of the notification information, and the process ends.

Details of the deletion notification information generation processing in step S11005 will be described below with reference to FIG.
FIG. 70 is a flowchart showing details of the deletion notification information generation processing in step S11005 of the third embodiment.

When the deletion notification information generating process is activated, the above-mentioned notification information is generated in step S 11301. In next step S11302, a "deletion" flag indicating that data has been deleted from the database is set in the notification type of the notification information. Sequential step S113
In 03, the information of the target database of the transaction itself is set in the target database of the notification information, and the process is terminated.

Details of the update notification information generation processing in step S11008 will be described below with reference to FIG.
FIG. 71 is a flowchart showing details of the update notification information generation processing in step S11008 of the third embodiment.

When the update notification information generation process is activated, the above-mentioned notification information is generated in step S11401. Subsequently, in step S11402, an "update" flag indicating that the data in the database has been updated is set in the notification type of the notification information. Succeeding, Step S11403
Then, the information of the target database of the transaction itself is set in the target database of the notification information, and the process ends.

Next, the DBM addition notification information notification processing in step S11003 will be described with reference to FIG.
FIG. 72 is a flowchart showing details of the DBM addition notification information notification processing in step S11003 according to the third embodiment.

When the DBM addition notification information notification process is activated, in step S11501 the transaction to be processed is set at the head of the mounted DB transaction management list of the DBM itself, and all transactions to be processed in the subsequent steps are performed. The process for is repeated.

[0287] In step S11502, it is determined whether the processing for all transactions to be processed is completed. If the processes for all transactions to be processed are complete (YES in step S11502), the process ends. On the other hand, if the processing for all transactions to be processed has not ended (N in step S11503).
O), and proceeds to step S11503.

[0288] In step S11503, transaction addition notification information notification processing provided by the transaction to be processed is executed to notify the corresponding database of the notification information. In next step S11504, the transaction to be processed is advanced to the next step, and step 11502 is executed again.
Return to and repeat the process.

Details of the DBM deletion notification information notification processing in step S11006 will be described below using FIG. FIG. 73 shows D in step S11006 of the third embodiment.
It is a flow chart which shows details of BM deletion notice information notice processing.

When the DBM deletion notification information notification process is activated, in step S11601 the transaction to be processed is set at the beginning of the mounted DB transaction management list of the DBM itself, and then all transactions to be processed in the next and subsequent steps. The process for is repeated.

[0291] In step S11602, it is determined whether the processing for all transactions to be processed has been completed. If the processing for all transactions to be processed is completed (NO in step S11602), the processing is completed. On the other hand, if the processing for all transactions to be processed has not ended (YES in step S11602).
S), and proceeds to step S11603.

In step S11603, the transaction deletion notification information notification processing provided by the transaction to be processed is executed, and the notification information is notified to the corresponding database. In next step S11604, the transaction to be processed is advanced to the next step, and step 11602 is executed again.
Return to and repeat the process.

Details of the DBM update notification information notification processing in step S11009 will be described below with reference to FIG. FIG. 74 shows D in step S11009 of the third embodiment.
It is a flow chart which shows the details of BM update notification information notification processing.

When the DBM update notification information notification process is activated, in step S11701 the transaction to be processed is set at the beginning of the mounted DB transaction management list of the DBM itself, and then all transactions to be processed in the subsequent steps are performed. The process for is repeated.

[0295] In step S11702, it is determined whether the processing for all transactions to be processed is completed. If the process for all transactions to be processed is completed (YES in step S11702), the process is completed. On the other hand, if the processing for all transactions to be processed has not ended (N in step S11702).
O), and proceeds to step S11703.

[0296] In step S11703, transaction update notification information notification processing provided by the transaction to be processed is executed, and notification information is notified to the corresponding database. In next step S11704, the transaction to be processed is advanced to the next step, and step 11702 is executed again.
Return to and repeat the process.

Details of the transaction addition notification information notification processing in step S11503 will be described below using FIG. FIG. 75 shows step S11 of the third embodiment.
It is a flowchart which shows the detail of the transaction addition notification information notification process of 503.

When the transaction addition notification information notification process is activated, it is determined in step S11801 whether the target database of the notification information matches the target database of the transaction itself. When the target database of the notification information does not match the target database of the transaction itself (N in step S11801)
O), there is no need to notify, so the processing ends as “success”. On the other hand, if the target database of the notification information matches the target database of the transaction itself (YES in step S11801), step S118
Go to 02.

[0299] In step S11802, a DB listener acquisition process is executed to acquire the previously registered database change notification destination. Then, in step S11803, it is determined whether acquisition of the database change notification destination has succeeded. If acquisition of the database change notification destination has not succeeded (NO in step S11803), the notification could not be made, and the processing ends as “failure”. On the other hand, if acquisition of the database change notification destination has succeeded (step S11)
If YES in step 803, the process advances to step S11804.

In step S11804, the DB listener addition notification information notification processing provided by the database change notification destination is executed, and the notification information is notified to the corresponding database.
The process ends as “success”.

Details of the transaction deletion notification information notification processing in step S11603 will be described below using FIG. FIG. 76 shows step S11 of the third embodiment.
6 is a flowchart showing details of a transaction deletion notification information notification process 603.

When the transaction deletion notification information notification processing is activated, it is determined in step S11901 whether the target database of the notification information matches the target database of the transaction itself. If the target database of the notification information does not match the target database of the transaction itself (N in step S11901)
O), there is no need to notify, so the processing ends as “success”. On the other hand, if the target database of the notification information matches the target database of the transaction itself (YES in step S11901), step S119
Go to 02.

In step S11902, DB listener acquisition processing is executed to acquire the previously registered database change notification destination. In step S11903, it is determined whether acquisition of the database change notification destination has succeeded. If acquisition of the database change notification destination has not succeeded (NO in step S11903), the notification cannot be made.
The process ends as “failure”.

On the other hand, if acquisition of the database change notification destination has succeeded (YES in step S11903), the flow advances to step S11904. In step S11904, the DB listener deletion notification information notification processing provided by the database change notification destination is executed, the notification information is notified to the corresponding database, and the processing ends as "success".

Details of the transaction update notification information notification processing in step S11703 will be described below using FIG. FIG. 77 shows step S11 of the third embodiment.
7 is a flowchart showing details of a transaction update notification information notification process of 703.

When the transaction update notification information notification processing is activated, it is determined in step S12001 whether the target database of the notification information matches the target database of the transaction itself. When the target database of the notification information does not match the target database of the transaction itself (N in step S12001)
O), there is no need to notify, so the processing ends as “success”. On the other hand, if the target database of the notification information matches the target database of the transaction itself (YES in step S12001), step S120
Go to 02.

[0307] In step S12002, a DB listener acquisition process is executed to acquire the previously registered database change notification destination. Next, in step S12003, it is determined whether acquisition of the database change notification destination has succeeded.
If acquisition of the database change notification destination has not succeeded (NO in step S12003), the notification could not be made, and the processing ends as “failure”. On the other hand, if acquisition of the database change notification destination has succeeded (step S12)
(YES in 003), the process proceeds to step S12004.

In step S12004, the DB listener update notification information notification processing provided by the database change notification destination is executed, and the notification information is notified to the corresponding database,
The process ends as “success”.

Details of the DB listener addition notification information notification processing in step S11804 will be described below using FIG. FIG. 78 shows step S1180 of the third embodiment.
It is a flowchart which shows the detail of the DB listener addition notification information notification process of FIG.

When the DB listener addition notification information notification processing is activated, display information update processing is executed in step S12101 to update the information being displayed corresponding to the notification information and redraw.

Details of the DB listener deletion notification information notification processing in step S11904 will be described below with reference to FIG. FIG. 79 shows step S1190 of the third embodiment.
It is a flowchart which shows the detail of the DB listener deletion notification information notification process of FIG.

When the DB listener deletion notification information notification processing is activated, display information update processing is executed in step S12201 to update the information being displayed corresponding to the notification information and redraw.

Details of the DB listener update notification information notification processing in step S12004 will be described below with reference to FIG. FIG. 80 shows step S1200 of the third embodiment.
It is a flow chart which shows details of DB listener update notice information notice processing of No. 4.

When the DB listener update notification information notification process is activated, the display information update process is executed in step S12301 to update the information being displayed corresponding to the notification information and redraw.

As described above, according to the third embodiment, a notification destination for notifying a database change is registered in a database that stores permanent data, and a series of database transactions for the database are managed. Keep it. Then, when there is a change in the database handled by the database transaction itself, the management destination managing the database transaction is notified, and when the management destination is notified of the change in the database, the plurality of databases managed by the database itself Notify the transaction of the change. in addition,
The changed content is notified to the corresponding registered notification destination.

As a result, the relevant application program can be notified of the change in the database, and each application program can execute appropriate processing. In addition, it is possible for the application to know the change of the target database without restricting that the data being accessed by other application programs cannot be accessed. Process can be executed and appropriate process can be implemented.

<Fourth Embodiment> FIG. 81 is a view showing the functional arrangement of an information processing apparatus according to the fourth embodiment.

FIG. 81 shows a server & remote configuration when accessing databases existing in different devices. In addition, the application program 130
A configuration for accessing the database 13008 existing in the device 13005 different from 02 will be described.

Since the mounted DB transaction 13007 that accesses the database 13008 existing in the device 13005 does not have the inter-device communication means, the direct application program 13002 is used.
Unable to provide services to. Therefore, the mounting server DB transaction 13006 having the inter-device communication means is used to execute the mounting DB transaction 13 described above.
By extending 007, it is possible to provide a service to the application program 13002 (in the figure, the server-mounted DB transaction 1300).
4 is the server mounted DB transaction 13006
Is used in the device 13001).

However, in order to use the server-implemented DB transaction 13004 as it is, the application program 13002 needs to be implemented differently from the local database, resulting in complication. Therefore, the application program 13002 can be accessed in the same manner as the local database by extending the server mounting DB transaction 13004 with the remote mounting DB transaction 13003 that absorbs the difference in the mounting.

Next, the hierarchical DB transaction structure of the fourth embodiment will be described with reference to FIG.

FIG. 82 is a diagram showing the hierarchical DB transaction structure of the fourth embodiment.

DB manager 13102 of the fourth embodiment
Is a DB transaction 1 that handles a series of transactions with the database 13105 corresponding to the request from the application program A 13101.
3103 is generated and discarded. Here, the DB transaction 13103 is the application program A13.
101 and an implementation DB transaction A13104 which is a database interface layer depending on the implementation of each database.

On the other hand, in response to a request from the application program X13110 executed on a device different from the above, the DB manager 13111 creates a DB transaction 13112. Here, the DB transaction 13112 is a remote implementation DB transaction X13 in which the communication with the server implementation DB transaction X13106, which is an extension of the inter-device communication means, is hidden in the implementation DB transaction X13107 that handles a series of transactions with the database 13108.
I have 113.

As described above, the created DB transaction group is the installed DB transaction management list 1310.
9 is stored and managed. However, the server-mounted DB transaction X13106 and the remote-mounted DB transaction X13113 are not stored and managed in the mounted DB transaction management list 13109 because they only extend the communication means between devices.

Next, the flow of the notification information in the server & remote configuration according to the change in the database of the fourth embodiment will be described with reference to FIG. FIG. 83 is a diagram showing a flow of notification information in the server & remote configuration according to a change in the database of the fourth embodiment.

In FIG. 83, a DB transaction A13204 is generated using the DB manager 13203 existing on the same device 13201 as the application program 13202.

On the other hand, the application program 132
The remote DB transaction X13208 and the notification server 13209 are generated by using the DB manager 13210 existing on the same device 13207 as 11th. Then, a server DB transaction X13205 and a notification remote 13206 for performing inter-device communication are generated using the DB manager 13203 existing on a different device 13201.

Here, the DB transaction A1320
The notification information is notified to the DB manager 13203 according to the change generated by the processing performed in 4. The DB manager 13203 notifies the notified notification information to the managed DB transaction A 13204 and server DB transaction X 13205. The DB transaction A 13204 that has received the above notification notifies the application program 13202.

On the other hand, the server DB transaction X13
205 performs inter-device communication via the notification remote 13206, and notifies the notification server 1 of the different device 13207.
3209 to the application program 132
Notify 11

By the above flow, it becomes possible to notify the notification information even to the application programs existing in different devices, and the application program which has received the above notification information makes a judgment according to each judgment.
Perform appropriate processing such as redisplaying database information.

Next, the internal data of the hierarchical DB transaction of the fourth embodiment will be described with reference to FIG.
FIG. 84 is a diagram showing internal data of the hierarchical DB transaction of the fourth embodiment.

As shown in 13302, the hierarchical DB transaction is information 13303 of the actually installed DB transaction, the application object that is the processing target after the transaction is generated, and D.
It has internal data of an object correspondence table 13304 that stores the relationship of B objects.

Here, in FIG. 84, the mounting DB transaction 13303 is a remote mounting DB transaction for accessing the device 13301 being executed by the application program 13306 and the database 13311 existing in a different device 13307. Specifically, the internal data of the remote mounting DB transaction has a server mounting DB transaction 13308 of a different device 13307.

On the other hand, the implementation DB for actually accessing the database 13311 inside the server implementation DB transaction 13308 existing in the device 13307.
It has a transaction 13309.

Information 13 of the above mounted DB transaction
309, a DB listener that has information to notify the change of the database, an execution status that indicates whether the transaction is being executed, information 13311 of the database that is the target of the transaction, and information that is executed while the transaction is being executed. Undetermined processing list 1331
2 and the update status that holds the change status of the database.

Here, the actual entity of the DB listener shows the notification remote 13310 for realizing the inter-device communication without directly showing the application. Furthermore, the notification remote 13310 is used by the notification server 133.
By communicating with 05, it is possible to notify the application program 13306 existing in a different device.

Next, step S60 in the fourth embodiment.
Details of the DB transaction generation processing of No. 3 will be described with reference to FIG. FIG. 85 is a flowchart showing details of the DB transaction generation processing in step S603 of the fourth embodiment.

When the DB transaction generation processing is activated, initialization processing is executed in step S13401.
The internal data of the hierarchical DB transaction described in FIG. 84 is initialized. Subsequently, in step S13402, FIG.
It is determined whether the server name specified on the transaction generation screen described in 4 is valid. If the server name is valid (YES in step S13402), the process advances to step S13410.

In step S13410, a remote mounting DB transaction generation process is executed to generate a DB transaction for connecting to the server designated by the server name. As a result of the remote mounting DB transaction generation processing, it is determined in subsequent step S13411 whether or not the generation of the DB transaction has succeeded. When the DB transaction is successfully generated (step S13)
(YES in 411), the process ends as “success”. On the other hand, if the DB transaction generation has not succeeded (NO in step S13411), the processing ends as “failure”.

On the other hand, if the server name is not valid in step S 13402 (NO in step S 13402), the flow advances to step S 13403. In step S13403, a corresponding database manager generation process is executed,
The database manager specified on the transaction generation screen described in FIG. 84 is generated. Subsequently, in step S13404, the implementation DB transaction initialization processing provided by the database manager generated above is executed to initialize the internal data of the implementation DB transaction described in FIG.

[0342] In subsequent step S13405, the DB connection processing provided by the database manager generated above is executed to connect to the database under the specified conditions. As a result of the DB connection processing, next, step S13406
Then, it is determined whether or not the database connection is successful.
If the connection is not successful (N in step S13406)
O), the processing ends as “failure”. On the other hand, if the connection is successful (YES in step S13406), the flow advances to step S13407.

In step S13407, information related to the connection is stored in the internal data of the mounting DB transaction. Next, in step S13408, the given database change notification destination is stored in the DB listener. next,
In step S13409, the generated mounted DB transaction is added to the mounted DB transaction management list, and the processing ends as “success”.

Details of the remote mounting DB transaction generation processing in step S13410 will be described below with reference to FIG.
This will be described using 6. FIG. 86 shows step S of the fourth embodiment.
13 is a flowchart showing details of a remote mounting DB transaction generation processing of 13410.

When the remote mounting DB transaction generation process is activated, a service name generation process is executed in step S13501 to generate the service name of the server DB manager based on the given server name.

Next, in step S13502, a service acquisition process is executed to acquire the service corresponding to the generated service name. Succeeding, Step S13503
Then, it is determined whether or not the service is successfully acquired. If the acquisition of the service is not successful (step S1350)
If NO, the process ends as “failure”. On the other hand, if the service has been successfully acquired (YES in step S13503), the flow advances to step S13504.

In step S13504, a notification server generation process is executed to generate a notification server in which the inter-device communication means is expanded from the given DB listener. Next, in step S13505, a server-installed DB transaction generation process is executed, and the generated notification server is given to generate a server DB transaction. In next step S13506, the server mounting DB transaction is stored in the internal data of the remote mounting DB transaction, and the processing ends as “success”.

Details of the server-implemented DB transaction generation processing in step S13505 will be described below with reference to FIG.
Will be explained. FIG. 87 shows step S1 of the fourth embodiment.
It is a flow chart which shows details of server mounting DB transaction generation processing of 3505.

When the server-installed DB transaction generation process is activated, a notification remote generation process is executed in step S13601 to generate a notification remote concealed from the given notification server with the same interface as the local DB listener.

Next, in step S13602, a DB transaction generation process is executed to generate a DB transaction without specifying the server name. This DB transaction generation processing is the same as the above-mentioned DB transaction generation processing, and since the server name is not specified, a local DB transaction is generated.

As a result of the DB transaction generation processing, in step S13603, it is determined whether the DB transaction has been successfully generated. When the transaction is not successfully generated (NO in step S13603)
Ends the processing as "failure". On the other hand, if the transaction has been successfully generated (YES in step S13603), the flow advances to step S13604 to store the DB transaction in the internal data of the server-mounted DB transaction, and the processing ends as “success”.

Next, step S11804 of the third embodiment.
FIG. 8 shows details of the notification remote addition notification information notification processing which is another form of the DB listener addition notification information notification processing of FIG.
This will be described using 8. 88 is a flowchart showing details of the notification remote addition notification information notification processing according to the fourth embodiment. In the DB listener addition notification information notification processing of the third embodiment, the notification information is notified to the notification destination existing on the local device, but here, a specific method of notifying the notification information to the notification destination existing on a different device will be described. Explained.

When the notification remote addition notification information notification process is activated, a notification server acquisition process is executed in step S13701 to acquire the notification server from the information contained in the internal data of the notification remote. As a result of the notification server acquisition processing, it is determined in next step S13702 whether or not the acquisition of the notification server has succeeded. If acquisition of the notification server has not succeeded (NO in step S13702), the processing ends as “failure”. On the other hand, if acquisition of the notification server has succeeded (YES in step S13702), step S
Proceed to 13703.

In step S13703, the notification server addition notification information notification processing provided by the acquired notification server is executed, the notification information is notified to the corresponding database, and the processing ends as "success".

Next, step S11904 of the third embodiment.
FIG. 8 shows details of the notification remote deletion notification information notification processing which is another mode of the DB listener deletion notification information notification processing of FIG.
This will be described using 9. FIG. 89 is a flowchart showing details of the notification remote deletion notification information notification processing according to the fourth embodiment. In the DB listener deletion notification information notification processing of the third embodiment, the notification destination existing on the local device is notified, but a method of notifying the notification destination existing on a different device will be specifically described here.

When the notification remote deletion notification information notification process is activated, a notification server acquisition process is executed in step S13801 to acquire the notification server from the information contained in the internal data of the notification remote. As a result of the notification server acquisition processing, it is determined in step S13802 that the acquisition of the notification server has succeeded. If acquisition of the notification server has not succeeded (NO in step S13802), the processing ends as “failure”. On the other hand, if acquisition of the notification server has succeeded (YES in step S13802), step S
Proceed to 13803.

In step S13803, the notification server deletion notification information notification processing provided by the acquired notification server is executed, and the notification information is notified to the corresponding database.
The process ends as “success”.

Next, step S12004 of the third embodiment.
FIG. 9 shows details of the notification remote update notification information notification process which is another form of the DB listener update notification information notification process of FIG.
It will be described using 0. FIG. 90 is a flowchart showing details of the notification remote update notification information notification processing according to the fourth embodiment. In the DB listener update notification information notification process of the third embodiment, the notification destinations existing on the local device are notified, but here, a method of notifying the notification destinations existing on different devices will be specifically described.

When the notification remote update notification information notification process is activated, a notification server acquisition process is executed in step S13901 to acquire the notification server from the information contained in the internal data of the notification remote. As a result of the notification server acquisition processing, it is determined in subsequent step S13902 whether or not the acquisition of the notification server has succeeded. If acquisition of the notification server has not succeeded (NO in step S13902), the processing ends as “failure”. On the other hand, if acquisition of the notification server has succeeded (YES in step S13902), step S
Proceed to 13903.

[0360] In step S13903, the notification server update notification information notification processing provided by the acquired notification server is executed, and the notification information is notified to the corresponding database.
The process ends as “success”.

Details of the notification server addition notification information notification processing in step S13703 will be described below using FIG. FIG. 91 shows step S13703 of the fourth embodiment.
5 is a flowchart showing details of the notification server addition notification information notification process of FIG.

When the notification server addition notification information notification process is activated, a DB listener acquisition process is executed in step S14001 to acquire the previously registered database change notification destination. Next, in step S14002, it is determined whether acquisition of the database change notification destination has succeeded. If acquisition of the database change notification destination has not succeeded (NO in step S14002), the processing ends as “failure”. On the other hand, if acquisition of the database change notification destination has succeeded (YES in step S14002), step S
Proceed to 14003.

In step S14003, the DB listener addition notification information notification processing provided by the database change notification destination is executed, and the notification information is notified to the corresponding database,
The process ends as “success”.

Details of the notification server deletion notification information notification processing in step S13803 will be described below with reference to FIG. FIG. 92 shows step S13803 of the fourth embodiment.
5 is a flowchart showing details of notification server deletion notification information notification processing of FIG.

When the notification server deletion notification information notification process is activated, the DB listener acquisition process is executed in step S14101 to acquire the previously registered database change notification destination. Next, in step S14102, it is determined whether acquisition of the database change notification destination has succeeded. If acquisition of the database change notification destination has not succeeded (NO in step S14102), the processing ends as “failure”. On the other hand, if acquisition of the database change notification destination has succeeded (YES in step S14102), step S
Proceed to 14103.

In step S14103, the DB listener deletion notification information notification processing provided by the database change notification destination is executed, and the notification information is notified to the corresponding database,
The process ends as “success”.

Details of the notification server update notification information notification processing in step S13903 will be described below with reference to FIG. FIG. 93 shows step S13903 of the fourth embodiment.
5 is a flowchart showing details of the notification server update notification information notification process of FIG.

When the notification server update notification information notification process is activated, a DB listener acquisition process is executed in step S14201 to acquire the previously registered database change notification destination. Next, in step S14202, it is determined whether acquisition of the database change notification destination has succeeded. If acquisition of the database change notification destination has not succeeded (NO in step S14202), the processing ends as “failure”. On the other hand, if acquisition of the database change notification destination has succeeded (YES in step S14202), step S1
Proceed to 4203.

In step S14203, the DB listener update notification information notification processing provided by the database change notification destination is executed, and the notification information is notified to the corresponding database.
The process ends as “success”.

As described above, according to the fourth embodiment, the database remote operation in which the inter-device communication means is extended so that the database for storing permanent data can be operated by different devices, and the database remote operation can be performed by the same device. By concealing the database remote operation for concealing the same interface as the database operation, the database of the same device and the database of a different device can be operated in the same way.

As a result, in the same device, a method of operating a database existing in the same device and a database existing in a different device can be standardized without incurring the overhead for communication between the devices. For application developers, there is an effect that knowledge specific to the database and knowledge for implementing communication between devices are unnecessary.

Further, the database interface provider also has the effect of not requiring knowledge for expanding the inter-device communication means.

Here, FIG. 109 is an example of an application program incorporating a plurality of databases existing on different devices using the fourth embodiment.

Application program 103202
And a database aa103205 existing on the same device 103201 and a different device 103212.
Only the common database interface 103203 is incorporated to access the database 103211 existing in the.

At this time, inside the common database interface 103203, the registry interface 103208 of the device 103207 is used to acquire the server database interface 103209, which is an extension of the inter-device communication means, from the target common database interface 103210 existing in a different device. The remote database interface 10320 hidden by the common database interface 103203.
6 has been implemented.

Therefore, the application developer is not aware of the search method using the registry interface 103208, the mounting method of each database, and the difference in device, and the common database interface 1
You only need to install 03203. On the contrary, the database interface provider can expand those functions without being familiar with the registration method in the registry interface 103208 and the mounting method for expanding the inter-device communication means.

<Fifth Embodiment> FIG. 94 is a diagram showing the structure of a multi-layered cache by an information processing apparatus according to the fifth embodiment. In this embodiment, as shown in FIG. 94, a multi-layer cache structure having caches for the purpose of transaction and database is used. Figure 9
Transactions 15003, 1500 shown in 4
5, 15007 corresponds to the transactions generated in the first to fourth embodiments. However, in the fifth embodiment, a transaction cache is included as each transaction internal data (see FIGS. 96 and 97).

The database 15001 is encrypted and compressed and stored on, for example, a hard disk. Therefore, in order to access the object stored in the database, it has to be decrypted / decompressed, which causes overhead. Therefore, by using the database cache 15002, it is possible to hold the information of the object that has already been decrypted and decompressed, and avoid the overhead for the same object. Since the existence of the database cache 15002 is hidden from external processing such as a transaction, the system is not complicated.

On the other hand, each transaction has a transaction cache 15004, 15006 for holding the change contents before Commit (confirmation) or holding the information of the already accessed object to speed up. The isolation level is Read Uncommitted.
In the case of 1, the transaction common cache 15006 common to all transactions is shared because it is affected by the change before committing of other transactions.

In the case of other isolation levels, each transaction has an independent transaction individual cache 15004, and not only the changed contents are reflected in the database at the time of Commit, but also the above-mentioned transaction common cache 15006.
Also reflect. This allows the changes made by all the transactions to be reflected in the transaction common cache.

FIG. 95 is a diagram showing the structure of the database cache. The database 15101 includes a database entity 15102 and a database cache 15.
It is composed of 103.

As described above, the data stored in the database is encrypted / compressed and stored on the hard disk, for example, and must be decrypted / decompressed when accessed. On the other hand, the database cache 151
By holding the information 15104 of the object that has already been decrypted and decompressed in 03, it is intended to avoid the overhead for the same object.

If the database is searched under a certain condition by a transaction and an object group is obtained as a search result, the database cache 151
03 caches this. This eliminates the need to repeat the search process under the same condition.

FIG. 96 is a diagram showing the relationship between the internal information of two mounting DB transactions and the common transaction cache. The implementation DB transaction information 15201 and 15206 includes an execution status indicating whether or not the transaction is in progress, information 15202 of the database which is the target of the transaction,
It has a DB listener that has information to notify the change of the database, an update status that holds the change status of the database, and a transaction cache 15204.

Here, the different implementation DB transactions 15201 and 15206 refer to the same common transaction cache 15204 to mutually reflect the update results associated with the database operation.

FIG. 97 is a diagram showing the internal information of two mounting DB transactions and the relationship between the individual transaction caches. The implementation DB transaction information 15301 and 15306 includes an execution status indicating whether the transaction is being executed and the information 15 of the database that is the target of the transaction.
302, a DB listener that has information to notify the change of the database, an update status that holds the change status of the database, and a transaction cache 153.
04 and 15307.

Here, the different implementation DB transactions 15301 and 15306 refer to different individual transaction caches 15304 and 15307, respectively, so that the update results associated with the database operation do not affect each other.

The above transaction caches shown in FIGS. 96 and 97 are included in the transaction internal data shown in FIGS. 23 and 59.

The relationship between the database described in Embodiments 1 to 4 and the cache described in Embodiment 5 will be described below.

Creating, updating the database cache,
About write-back (reflection) Database cache is one-to-one for each database
This is to minimize access to the database entity that accompanies file access.

Therefore, when a particular database is accessed for the first time by an arbitrary transaction, the corresponding database cache is created and initialized. After that, when the same database is accessed by another transaction,
The corresponding existing database cache will be used. As a result, the database entity and the database cache can be uniquely associated with each other regardless of access by a plurality of different transactions.

On the other hand, when data is acquired by an arbitrary transaction, the database cache is updated in order to avoid a decrease in response due to accessing the substance of the database again. of course,
Due to the balance with the memory consumption, it is possible that you may not dare to update. Further, by the DB transaction confirmation process shown in FIG. 26, the contents of the change made to the transaction cache performed before that are reflected and the database cache is updated. In this case, it is necessary to update regardless of the consumed memory.

The timing of writing back (reflecting) the database cache to the database entity is explicitly instructed by the application, or when the system itself ends or the database cache consumption exceeds a certain value. If it happens, it will be done automatically. This makes it possible to realize a database cache within a limited size.

-Transaction cache generation, update, and write-back The transaction cache is for holding the changes made in each transaction. Here, the normal transaction cache is independent for each individual transaction and is not affected by other transactions, but the isolation level = Read Uncommitt.
When ed is specified, it is necessary to refer to the changes made before committing (Commit) in any transaction.
Use a common transaction cache.

The normal transaction cache is generated by the transaction start process of FIG. 25. However, the common transaction cache used when the isolation level = Read Uncommitted is specified is the first time that the isolation level = Read Uncommitted.
It is created when the transaction is created by the specification, and after that, the existing common transaction cache is referenced.

Also, when data is acquired, the transaction cache is updated in order to avoid a decrease in response due to access to the database again. Of course, it may not be possible to update it due to the balance with the consumed memory. Furthermore, the transaction cache is updated according to changes in the DB object generation / addition processing of FIG. 36, the DB object deletion processing of FIG. 37, the DB object value set processing of FIG. In this case, it is necessary to update regardless of the consumed memory.

The updated contents of the transaction cache are collectively reflected in the database by the DB transaction confirmation process of FIG.

Reflecting the contents of the individual cache in the common cache The common transaction cache is used when the isolation level = Read Uncommitted is specified.
Therefore, the updated content is always shared between transactions with the isolation level = Read Uncommitted. On the other hand, since it is necessary to reflect the contents of the update performed at other isolation levels, the DB object generation / addition processing of FIG. 36, the DB object deletion processing of FIG. 37, the DB object value setting processing of FIG. Upon modification, the common transaction cache is updated along with the transaction cache for each transaction individually.

FIG. 108 is a flow chart for explaining the cache operation according to the fifth embodiment. When an operation for an object occurs from a transaction, the process advances from step S15001 to step S15002,
Determine the isolation level of the transaction. If the isolation level is Uncommitted,
The process proceeds to step S15004, and it is determined whether the transaction common cache 15006 holds the target object. If the target object is held in the transaction common cache 15006, that is, if a cache hit occurs, the process advances to step S15007 to operate the object on the common cache.

On the other hand, if there is no cache hit in step S 15005, step S 15005
Proceeding to, the database 15001 is requested for the target object. If the object is acquired from the database 15001, step S15006
Holds it in the common cache. Then, the process advances to step S15007 to operate the object on the common cache.

If an operation is performed on the object and the isolation level is other than Uncommitted, the process advances to step S15008 to determine whether the target object is held in the transaction individual cache 15004. If the target object is held in the transaction individual cache 15004, that is, if a cache hit occurs, the process advances to step S15011 to operate the object on the common cache. After that, the process advances to step S15007.

On the other hand, if there is no cache hit in step S 15008, step S 15009
Proceeding to, the database 15001 is requested for the target object. If the object is acquired from the database 15001, step S15010.
Holds it in a separate cache at. Then, the process advances to step S15011 to operate the object on the individual cache. After that, step S15007
Go to.

If no operation has been performed on the object, it is determined in step S15012 whether or not it is the write-back timing for reflecting the contents held in the cache on the actual object. If it is the write-back timing, the process advances to step S15013 to write back the contents held in the cache to the database. When the same object as the object held in the transaction individual cache 15004 is held in the transaction common cache 15006, the common cache 15006 is updated with the contents of the individual cache 15004 for that object.

As described above, according to the fifth embodiment, in addition to providing an individual transaction cache for each transaction or a common transaction cache, all transactions are committed (committed).
By providing a database cache that reflects the results, the response when referencing the database can be improved.

By hiding the existence of the database cache inside, the above effect is realized without inviting complication.

Here, in FIG. 98, the fifth embodiment is used.
This is an example of referring to the same object from different transactions.

In order to refer to the object stored in the database 20103 from the transaction 1 shown in 20101, (1) the stored image of Object1 in the database can be referred to by the transaction.
Convert it to Object1 and store it in the database cache,
(2) Object stored in the database cache
After storing 1 in the transaction 1 cache,
(3) Obtained. On the other hand, in order to refer to the same object stored in the database 20103 from the transaction 2 indicated by 20102, (4) after storing Object 1 already stored in the database cache in the cache of transaction 2, (5) To be acquired.

As described above, by providing the database cache, the conversion from the stored image in the database does not have to be performed each time, so the response is improved.

[0409] Here, Fig. 99 is obtained by using the fifth embodiment.
This is an example of referring to the same object group from different transactions.

In order to refer to the object group stored in the database 20203 from the transaction 1 shown in 20201, (1) the object group matching the search condition is searched from the database and stored in the database cache, and (2) After the object group stored in the database cache is stored in the transaction 1 cache, (3) it is acquired. On the other hand, 20
To refer to the same object group stored in the database 20203 from the transaction 2 indicated by 202, (4) after storing the object group already stored in the database cache in the transaction 2 cache, (5) To be acquired. In this way, by providing the database cache, it is possible to avoid searching the database each time, so that the response is improved.

Even when the present invention is applied to a system including a plurality of devices (for example, a host computer, an interface device, a reader, a printer, etc.), a device including one device (for example, a copying machine or a facsimile device). Etc.)

Further, an object of the present invention is to supply a storage medium having a program code of software for realizing the functions of the above-described embodiments to a system or apparatus, and to supply a computer (or CPU) of the system or apparatus.
It is needless to say that it can be achieved by reading and executing the program code stored in the storage medium.

In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the storage medium storing the program code constitutes the present invention.

A storage medium for supplying the program code is, for example, a floppy disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD.
-R, magnetic tape, non-volatile memory card, ROM, etc. can be used.

Further, not only the functions of the above-described embodiments are realized by executing the program code read by the computer, but also the OS (operating system) running on the computer based on the instructions of the program code. It is needless to say that this also includes a case where the above) performs a part or all of the actual processing and the processing realizes the functions of the above-described embodiments.

Further, after the program code read from the storage medium is written in the memory provided in the function expansion board inserted into the computer or the function expansion unit connected to the computer, based on the instruction of the program code, It goes without saying that a case where the CPU or the like included in the function expansion board or the function expansion unit performs some or all of the actual processing and the processing realizes the functions of the above-described embodiments is also included.

[0417]

As described above, according to the present invention,
It is possible to provide an information processing apparatus and method capable of improving response when referring to a database, and a computer-readable memory.

[Brief description of drawings]

FIG. 1 is a block diagram showing a hardware configuration of an information processing apparatus of this embodiment.

FIG. 2 is a flowchart showing processing executed by the information processing apparatus of this embodiment.

FIG. 3 is a diagram showing an example of a database processing screen of this embodiment.

FIG. 4 is a flowchart showing details of database processing in step S205 of the present embodiment.

FIG. 5 is a diagram showing an example of a transaction generation screen of the present embodiment.

FIG. 6 is a flowchart showing details of transaction generation processing in step S406 of the present embodiment.

FIG. 7 is a diagram showing an example of a transaction processing screen of the present embodiment.

FIG. 8 is a flowchart showing details of transaction processing in step S408 of this embodiment.

FIG. 9 is a diagram showing an example of an additional object selection screen of the present embodiment.

FIG. 10 is a flowchart showing details of object selection / addition processing corresponding to an instruction to add an object in the event handling processing according to the present embodiment.

FIG. 11 is a diagram showing an example of an object edit screen when creating a new object according to the present embodiment.

FIG. 12 is a flowchart showing details of object generation processing in step S1006 of the present embodiment.

FIG. 13 is a diagram showing an example of a class selection screen of the present embodiment.

FIG. 14 is a diagram showing an example of an object edit screen when editing an existing object according to the present embodiment.

FIG. 15 is a flowchart showing details of object selection / editing processing according to the present embodiment.

FIG. 16 is a diagram showing an example of an object reference screen when referring to an existing object of the present embodiment.

FIG. 17 is a flowchart showing details of object selection / deletion processing of the present embodiment.

FIG. 18 is a flowchart showing details of all object acquisition confirmation processing in steps S1503 and S1703 of the present embodiment.

FIG. 19 is a flowchart showing details of object addition confirmation processing in step S1007 of the present embodiment.

FIG. 20 is a flowchart showing details of object update confirmation processing in step S1509 of this embodiment.

FIG. 21 is a flowchart showing details of object deletion confirmation processing in step S1709 of this embodiment.

FIG. 22 is a diagram showing a functional configuration of the information processing apparatus of this embodiment.

FIG. 23 is a diagram showing internal data of a DB transaction of this embodiment.

FIG. 24 is a flowchart showing details of the DB transaction generation processing in step S603 of this embodiment.

FIG. 25 shows steps S1801, S1901, S2001, and S2101 of this embodiment.
5 is a flowchart showing details of the DB transaction start processing of FIG.

FIG. 26 shows steps S1804, S1904, S2004, and step S2104 of this embodiment.
9 is a flowchart showing details of the DB transaction confirmation process of FIG.

FIG. 27 shows steps S1805, S1905, S2005, and S2105 of this embodiment.
6 is a flowchart showing details of the DB transaction cancellation process of FIG.

FIG. 28 is a diagram showing a relationship between objects used in the information processing apparatus of the present embodiment.

FIG. 29 is a diagram showing a programming code of an application object of the present embodiment.

FIG. 30 is a diagram showing a list of database objects of the present embodiment.

FIG. 31 is a flowchart showing details of all object acquisition processing in step S1802 of the present embodiment.

FIG. 32 is a flowchart showing details of object addition processing in step S1902 of this embodiment.

FIG. 33 is a flowchart showing details of object update processing in step S2002 of the present embodiment.

FIG. 34 is a flowchart showing details of object deletion processing in step S2102 of the present embodiment.

FIG. 35 is a flow chart showing details of all DB object acquisition processing in step S5902 of the present embodiment.

FIG. 36 is a flowchart showing details of DB object generation / addition processing in step S6002 of the present embodiment.

FIG. 37 is a flowchart showing details of DB object deletion processing in step S6204 of this embodiment.

FIG. 38 is a flowchart showing details of the DB object value setting process in steps S5907 and S6003 of this embodiment.

FIG. 39 is a flowchart showing details of object generation processing in step S5906 of this embodiment.

FIG. 40 is a flowchart showing details of object value setting processing in step S5907 of the present embodiment.

FIG. 41 is a flowchart showing details of all writable field name acquisition processing in steps S7301 and S7501 of the present embodiment.

FIG. 42 is a diagram showing hierarchically structured database operating means of the information processing apparatus according to the second embodiment.

FIG. 43 is a diagram showing a hierarchical DB transaction structure according to the second embodiment.

FIG. 44 is a diagram showing internal data of a hierarchical DB transaction according to the second embodiment.

FIG. 45 is a diagram showing an example of a transaction generation screen when selecting a database type according to the second embodiment.

FIG. 46 is a diagram showing an example of a transaction generation screen when a server name is input according to the second embodiment.

FIG. 47 is a flowchart showing details of DB transaction generation processing according to the second embodiment.

FIG. 48 is a diagram showing an example of a relationship between packages, which is a set of some purposes of the hierarchical DB transaction structure of the second embodiment.

FIG. 49 is a diagram showing an example of a relationship between classes of the hierarchical DB transaction structure according to the second embodiment.

FIG. 50 is a diagram showing an example of a basic class hierarchy of a hierarchical DB transaction structure according to the second embodiment.

FIG. 51 is a diagram showing an example of a hierarchical transaction structure when a database exists on the same device as the application program of the second embodiment.

FIG. 52 is a diagram showing an example of a basic class hierarchy when extended to the local database according to the second embodiment.

FIG. 53 is a diagram showing an example of a hierarchical DB transaction structure when a database exists on a device different from the application program of the second embodiment.

FIG. 54 is a diagram showing an example of a basic class hierarchy when extended to the remote database of the second embodiment.

FIG. 55 is a diagram showing an example of a hierarchical DB transaction structure when a database service is provided to application programs on different devices according to the second embodiment.

FIG. 56 is a diagram showing an example of a basic class hierarchy when the remote interface is extended so that the database IF layer of the second embodiment can be used by different devices.

[Fig. 57] Fig. 57 is a diagram showing the flow of notification information accompanying a change in the database etc. of the third embodiment.

FIG. 58 is a diagram showing a hierarchical DB transaction structure of the information processing apparatus according to the third embodiment.

FIG. 59 is a diagram showing internal data of a hierarchical DB transaction according to the third embodiment.

FIG. 60 is a flowchart showing details of the transaction discarding process of step S409 of the third embodiment.

FIG. 61 is a flowchart showing details of DB transaction generation processing according to the third embodiment.

FIG. 62 is a flowchart showing details of a DB transaction discarding process in step S10301 according to the third embodiment.

FIG. 63 is a flowchart showing details of DB object generation / addition processing in step S6002 of the third embodiment.

FIG. 64 is a flowchart showing details of DB object deletion processing according to the third embodiment.

FIG. 65 is a flowchart showing details of DB object value setting processing in steps S5907 and S6003 of the third embodiment.

FIG. 66 is step S1804, step S1904, step S2004, step S2104 of the third embodiment.
9 is a flowchart showing details of the DB transaction confirmation process of FIG.

FIG. 67 is a flowchart showing details of update information generation notification processing in step S10906 of Embodiment 3.

FIG. 68 is a diagram showing an example of notification information generated in the update notification information generation processing of step S11008 of Embodiment 3;

FIG. 69 is a flowchart showing details of additional notification information generation processing in step S11002 according to the third embodiment.

FIG. 70 is a flowchart showing details of deletion notification information generation processing in step S11005 of the third embodiment.

FIG. 71 is a flowchart showing details of update notification information generation processing in step S11008 of Embodiment 3.

FIG. 72 is a DBM of step S11003 of the third embodiment.
It is a flow chart which shows the details of addition notice information notice processing.

FIG. 73 is a DBM of step S11006 of the third embodiment.
7 is a flowchart showing details of deletion notification information notification processing.

FIG. 74 is a DBM of step S11009 of the third embodiment.
7 is a flowchart showing details of update notification information notification processing.

FIG. 75 is a flowchart showing details of transaction addition notification information notification processing in step S11503 of Embodiment 3.

FIG. 76 is a flowchart showing details of transaction deletion notification information notification processing in step S11603 of Embodiment 3.

77 is a flowchart showing details of the transaction update notification information notification processing in step S11703 of Embodiment 3. FIG.

FIG. 78 is a flowchart showing details of DB listener addition notification information notification processing in step S11804 of Embodiment 3.

FIG. 79 is a flowchart showing details of DB listener deletion notification information notification processing in step S11904 of Embodiment 3.

FIG. 80 is a flowchart showing details of DB listener update notification information notification processing in step S12004 according to the third embodiment.

FIG. 81 is a diagram showing a functional configuration of an information processing device according to a fourth embodiment.

FIG. 82 is a diagram showing a hierarchical DB transaction structure according to the fourth embodiment.

FIG. 83 is a diagram showing a flow of notification information in the server & remote configuration according to a change in the database of the fourth embodiment.

FIG. 84 is a diagram showing internal data of a hierarchical DB transaction according to the fourth embodiment.

FIG. 85 is a flowchart showing details of DB transaction generation processing in step S603 of the fourth embodiment.

FIG. 86 is a flowchart showing details of remote-mounting DB transaction generation processing in step S13410 of the fourth embodiment.

FIG. 87 is a flowchart showing details of server-mounted DB transaction generation processing in step S13505 of Embodiment 4.

FIG. 88 is a flowchart showing details of notification remote addition notification information notification processing according to the fourth embodiment.

FIG. 89 is a flowchart showing details of notification remote deletion notification information notification processing according to the fourth embodiment.

FIG. 90 is a flowchart showing details of notification remote update notification information notification processing according to the fourth embodiment.

FIG. 91 is a flowchart showing details of the notification server addition notification information notification processing in step S13703 of Embodiment 4.

FIG. 92 is a flowchart showing details of the notification server deletion notification information notification processing in step S13803 of Embodiment 4.

FIG. 93 is a flowchart showing details of the notification server update notification information notification processing in step S13903 of the fourth embodiment.

FIG. 94 is a diagram showing a multi-tiered cache structure according to the fifth embodiment, in which a transaction and a database each have a cache.

FIG. 95 is a diagram showing a database cache structure according to the fifth embodiment.

FIG. 96 is a diagram showing a relationship between two internal DB transaction internal information items and a common transaction cache according to the fifth embodiment.

[Fig. 97] Fig. 97 is a diagram showing a relationship between two internal DB transaction internal information items and individual transaction caches according to the fifth embodiment.

[Fig. 98] Fig. 98 is a diagram illustrating an example of a flow of referring to the same object from different transactions.

[Fig. 99] Fig. 99 is a diagram illustrating an example of a flow of referring to the same object group from different transactions.

FIG. 100 is a table showing presence / absence of a cache according to an isolation level of a conventional technique.

FIG. 101 is a table showing operation allowance levels by other transactions according to the isolation level of the related art.

FIG. 102 is a diagram showing an example of a flow of referring to the same object stored in a database using a conventional technique.

[Fig. 103] Fig. 103 is a diagram illustrating an example of a flow when referring to the same object stored in a database using a conventional technique.

FIG. 104 is a diagram showing an example of a flow of referring to the same object stored in a database using a conventional technique.

FIG. 105 is a diagram showing an example of a flow of referring to the same object group stored in a database using a conventional technique.

FIG. 106 is a diagram showing an example of a flow of referring to the same object group stored in a database by using the conventional technique.

[Fig. 107] Fig. 107 is a diagram illustrating an example of a flow of referring to the same object group stored in a database using a conventional technique.

FIG. 108 is a flowchart illustrating cache control according to the fifth embodiment.

FIG. 109 is a diagram showing an example of an application program incorporating a plurality of databases existing on different devices using the fourth embodiment.

Claims (11)

[Claims] 1. An information processing apparatus for managing a database, comprising: generating means for generating a transaction for accessing an object managed by the database; and an object acquired and edited by the transaction generated by the generating means. Providing a cache memory for the database;
An information processing apparatus comprising: a second cache unit that caches an object acquired from the database by a transaction. 2. The first cache means holds an object acquired at a transaction level affected by an operation from another transaction in a common cache that can be referenced and operated by another transaction. The information processing apparatus according to claim 1, which is characterized in that. 3. The first cache unit holds an object acquired at a transaction level that is not affected by an operation from another transaction, in an individual cache accessible only from the transaction. The information processing device according to claim 1. 4. The database manages encoded objects, further comprising a decoding unit for decoding and providing an object requested to be acquired by the transaction, and the second cache unit is decoded by the decoding unit. The information processing apparatus according to claim 1, wherein the created object is cached. 5. A search unit for searching the database under the search condition given by the transaction to obtain an object group and providing the object group to the transaction, wherein the second cache unit caches the object group. The information processing apparatus according to claim 1, wherein: 6. An information processing method for managing a database, comprising a generation step of generating a transaction for accessing an object managed by the database, and an object acquired and edited by the transaction generated in the generation step. Providing a cache memory for the database;
A second cache step of caching an object acquired from the database by a transaction. 7. The first cache step is to retain an object acquired at a transaction level affected by an operation from another transaction in a common cache that can be referred to and operated by another transaction. The information processing method according to claim 6, which is characterized in that. 8. The first cache step retains an object acquired at a transaction level that is not affected by an operation from another transaction, in an individual cache accessible only by the transaction. The information processing method according to claim 6. 9. The database further comprises a decoding step of managing encoded objects, decoding the object requested to be acquired by the transaction and providing the object, and the second cache step decoding by the decoding step. The information processing method according to claim 6, wherein the created object is cached. 10. A control program for causing a computer to execute the information processing method according to claim 6. 11. A storage medium storing a control program for causing a computer to execute the information processing method according to claim 6.