JP2002297430A - Transaction-processing-type database system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a transaction-processing-type database system that is easy to construct and can flexibly deal with the function modification or the like. SOLUTION: A transaction execution request from an application is accepted with a transaction accepting part 3. In a transaction registration part 12A, a registration part 403 that registers the library of transactions that get access to the database (lexicon set) is provided. A setting part 404 that takes individual transaction as the access target and sets the access mode for a lexicon 21 included in the lexicon set 2 is provided. A relating part 405 that brings the transaction into one-to-one correspondence with a transaction function is provided. A DDL loading part 407 that loads the DDL file of the transaction function corresponding to the library is provided.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a database system implemented on a main memory of a computer, and in particular, to database management, transaction management and backup, failure recovery, and load distribution. The present invention relates to a transaction processing database system having various functions such as system management and suitable for supporting an application system built on the Internet / intranet.

[0002]

2. Description of the Related Art In a database system for monitoring and controlling shared data between machines distributed on a network in real time, a large amount of data is processed at high speed (search /
Update), the performance of the data management system that provides access to those data determines the performance of the database system. In order to improve the performance of such a data management system, it is conceivable to arrange and manage all data stored in an external storage device such as a hard disk in a main storage. In particular,
Due to the recent increase in main storage capacity, it has become possible to make all data reside in main storage even in the current hardware environment.

However, simply caching a conventional data management system on the premise of an external storage device using a main storage cannot achieve the performance required by a real-time application. The reason is that (a) a large amount of data transfer operation is required between the application and the data management system, and (b) an algorithm designed on the assumption of an external storage device is executed on the main storage of each machine. Even if the performance does not improve much 2
Points. Further, in an algorithm designed on the premise of an external storage device, the functions that the data management system can provide are limited. Therefore, even if the speed is somewhat increased, the development load of the application is not reduced.

In recent years, many systems requiring high reliability, such as systems that operate 24 hours a day, 365 days, have been increasing. In such a system, system down is not allowed under any circumstances. Therefore, a multiplex system configuration is often adopted. Also, middleware (MW) and hardware (HW) for supporting such functions must be controlled by application software. As a result, the above functions and access to data structures must be realized at the same time, and even if the reliability of the system is increased in a multiplex system, not only the application becomes complicated, but also bugs tend to remain, This is a factor that lowers the quality of the application. For this reason, there has been a strong demand for the development of a means that can easily implement a setting of a database management system and a function of enhancing data reliability.

[0005]

As described above, the conventional database system is inadequate in terms of high speed, reliability, and high functionality, and more specifically, has the following problems. There was a point.

(1) System halt due to function change If a function is modified or expanded during the development of the system, a situation that cannot be handled by the original data structure may occur. If such a situation occurs, change the database and take action, but when changing the database, the system must be shut down. However, if a change in functions occurs after the system starts operating, enormous costs are incurred when the system is stopped. In addition, the inability to change the functions without stopping the system means a decrease in maintainability.

(2) Difficulty of Changing the Structure Often, the function is modified or expanded during the life cycle of the system. At the time of designing the system, a function may be added that could not have been anticipated, and a situation that cannot be handled by the original data structure may occur. In such a case, by changing the database to cope with the problem, a patch data structure tends to be formed, and if such a data structure is used, maintainability is significantly reduced.
Productivity and performance will be degraded.

(3) Deterioration of Productivity at the Time of Developing a Large-Scale System In the development of a large-scale system, many developers are involved in application development at the same time. Data structures are designed for many applications and often do not take into account the specific characteristics of each application. This often results in a data structure that is very difficult for application developers to use. Since there is no development style including a data structure development method for large-scale development, regression and unnecessary processing occur, and productivity is deteriorated.

(4) Difficulty of Local / Remote Processing When performing processing (transaction) on a remote machine, a conventional database management system uses an RPC (Rem
ote Procedure Call). However, according to such a method, when a transaction is executed on a remote machine, the processing procedure in the application changes, and it takes more time than execution on the local machine.

[0010] The present invention has been proposed to solve the problems of the prior art as described above.
It is an object of the present invention to provide a transaction processing type database system which can easily construct a system and can flexibly cope with a function change or the like. Another object of the present invention is to provide a database management system capable of managing, with high accuracy, shared data held on main memories of a plurality of machines connected by a network, and to easily execute various settings in the management system. It is an object of the present invention to provide a transaction processing type database system which can perform the processing.

[0011]

According to one aspect of the present invention, there is provided a database provided in a main storage area of a computer, a transaction processing unit for executing a process for the database, A transaction management unit that manages a transaction executed by the transaction processing unit.
The transaction management unit prepares a transaction function necessary for executing each transaction, and when a transaction is issued, selects a transaction function corresponding to the issued transaction, and uses this transaction function. And performs processing on the database.

According to a second aspect of the present invention, the first aspect of the present invention is grasped from an apparatus point of view, and a database arranged in a main storage area of a computer and a program for executing processing on the database. A transaction processing unit; and a transaction management unit that manages transactions executed by the transaction processing unit. The transaction management unit includes a transaction registration management unit for selecting a transaction function corresponding to the issued transaction in advance. When,
And a transaction function loading unit for loading the selected transaction function and performing processing on the database.

According to the first or second aspect of the present invention, access to data is performed through the transaction function, and a change in the data structure does not propagate to the application. .

According to a third aspect of the present invention, a database is arranged on a main storage area of a plurality of computers connected via a network, and data stored in a specific computer is used as original data. A computer having the same base data as the base host, and another computer different from the specific computer stores the same replica data as the original data stored in the base host, and the computer storing the replica data is used as a replica. A host, a replication processing unit for ensuring the sameness of the original data of the base host and the replica data of the replica host on the main storage area of each host, and transaction processing for performing various processes on the database Department and A transaction management unit that manages a transaction executed by the transaction processing unit. The transaction management unit prepares a transaction function necessary to execute each transaction. In such a case, a transaction function corresponding to the issued transaction is selected, and processing on the database is executed using the transaction function.

According to a fourth aspect of the present invention, the invention of the third aspect is grasped from an apparatus point of view. The transaction management unit includes a transaction receiving unit and a transaction function corresponding to the received transaction. A transaction registration management unit for selecting
And a transaction function loading unit for loading the selected transaction function and performing processing on the database.

According to the third and fourth aspects of the present invention, since the system of the present invention consistently undertakes maintenance and management of shared data via the network, the existence of the network is provided to the application. On the other hand, it has an abstract concept of concealing a main storage area. That is, the application can access the shared data as a high-speed access to the main storage data only by participating in the service of the main storage area. This is a great advantage in developing a system distributed over a network.

According to a fifth aspect of the present invention, the database includes:
A lexicon as a data processing unit, and a lexicon set having one or more lexicons. In the transaction management unit, one or a plurality of transactions for performing processing on the lexicon are processed as transaction libraries in the lexicon set. It is characterized by being registered.
According to the fifth aspect of the present invention, processes such as registration and change can be easily performed as compared with a case where individual transactions are registered one by one in data to be accessed. Further, by grouping a plurality of transactions as a library, it becomes easy to handle a transaction function necessary for executing the transaction.

According to a sixth aspect of the present invention, the transaction includes a reference transaction that does not involve a change in data to be processed and an update transaction that makes a change in the data. It is characterized in that whether a transaction of reference or update accesses a lexicon in advance. According to the sixth aspect of the present invention, reference / update can be checked not for the entire lexicon set (database) but for each lexicon (part) constituting the lexicon set (database).

According to a seventh aspect of the present invention, in the transaction management section, the transaction function is stored as a DLL file, the DLL file is associated with the transaction library, and when the transaction registered in the transaction library is executed, A DLL file associated with a library is called, and a transaction function stored therein is executed. According to the seventh aspect of the present invention having such a configuration, a library (a plurality) is associated with a lexicon set, not a transaction, and a DLL file is associated with the library.
Even when the configuration contents of the L file are different, the link between the transaction function name and the program can be efficiently performed.

According to an eighth aspect of the present invention, the transaction management unit registers a real name and an alias for the lexicon set to be accessed by the transaction, and when the transaction is executed, the real name and the alias of the lexicon set are registered. In any case, it is characterized in that a lexicon set in which a transaction is registered can be accessed. According to the invention of claim 8 having such a configuration, a transaction issued by an application can be processed as a transaction for another database without changing the database designation identifier.

According to a ninth aspect of the present invention, the database stored in any one of the plurality of hosts stores original data of the system management data created by the transaction management unit, and has the original of the system management data. The host is provided with a system management application program and a system management transaction executed by the system management application program. The system management transaction includes a transaction executed by the transaction processing unit and a transaction processing of each transaction. It is characterized in that it is associated with target data. As described above, according to the ninth aspect of the present invention, as with the user application, the various settings of the system can be processed by the transaction, and the consistency of the system development is ensured.

[0022]

Next, embodiments of the present invention will be specifically described with reference to the drawings. Note that a portion related to information processing in this embodiment is typically realized by controlling a computer with software. The software in this case realizes the operation and effect of the present invention by physically utilizing the hardware of the computer, and the conventional technology is applied to the common parts with the conventional technology. However, in this case, since the types and configurations of hardware and software, the range of processing by software, and the like can be variously changed, a virtual circuit block that realizes each function of the present invention and the embodiment will be used in the following description. .

[1. Overview of distributed data management system]
The present invention relates to a distributed data management system for appropriately and efficiently managing databases provided in a plurality of machines connected by a network.

Although the details of the present invention will be described later, the distributed data management system of the present invention (hereinafter, referred to as the present system) will be outlined here. That is, the present system handles a database (lexicon set) and a transaction, receives a group of operation requests for reference, search, and update of the contents of the database from an application (= user) as a transaction, and appropriately receives the transaction. The application is executed, and an execution completion notification and an execution result are notified to the application as necessary (request).

FIG. 1 is a diagram showing the configuration of a distributed data management system according to the present invention. That is, the system
As shown in FIG. 1, a plurality of computers A, B, C,.
(Called each host) by a communication network. In the main storage areas of the hosts A, B, and C, the databases 1a, 1b, 1
c and transaction functions 2a, 2b, 2c for accessing the database.

One or a plurality of applications are executed on each host. When the system is composed of a plurality of hosts, different applications are often executed on different hosts. That is, the applications X, Y, and Z are outside the present system and access the database for each host to perform necessary processing. In this case, each of the applications X, Y, and Z communicates with a transaction function 2 registered in advance in the system via processing units 3a, 3b, and 3c provided in each host.
a, 2b, and 2c are requested to perform processes such as reference and update, and upon receiving the results, perform processes necessary for executing the program other than accessing the database. Normally, an application performs front-end processing such as display on a screen and printing.

(Database) The databases 1a, 1b and 1c of the present system are composed of one or more parts (lexicon). This lexicon selectively accesses the data portion of the lexicon set,
A unit for giving an attribute, which is uniquely identified by a name (lexicon name) or the like. In the execution environment of the present system, as shown in FIG. 2, since a unispace can include a plurality of lexicon sets, the lexicon sets are also identified by names (lexicon set names). Furthermore, the Unispace may also be implemented as a system that manages multiple Unispaces, i.e., different sets of lexicon sets, using a common network on the same physical machine. (Unispace name).

In the lexicon set stored in the database of each host, the original data is held on one of the hosts, and the replica data, which is a copy thereof, is held on the other hosts. For example,
In FIG. 1, a host A (computer A) holds original data of data B, and a host C (computer C) holds original data of data A. Also, the host B (computer B)
Replica data of data A and data B is held. Further, in the present system, data update processing can be executed only for original data, and data update processing cannot be performed for replica data.

(Transaction) A procedure in which an operation to be performed by a transaction is abstracted / generalized is called a “transaction function”. That is, the transaction functions (TR functions) A and B shown in FIG. 1 are functions that access the database of each machine and implement the processing required for all applications. That is, in the present system, each of the applications X, Y, and Z does not directly access the database to perform processing, but accesses the database via a transaction function.

Each transaction includes an identifier (transaction name or the like) for giving various attributes. For example, a transaction function to be executed is associated with this identifier. This identifier may be set to a required number according to the type of attribute to be assigned.

The target of a transaction is one lexicon set. In this system,
Since Unispace can include a plurality of lexicon sets, the transaction specifies the lexicon set to be operated. This lexicon set name may be considered as one of the above identifiers. Of course, means for determining the lexicon set to be operated from other identifiers can be provided, and it is not essential to specify the lexicon set name.

In the present system, a data operation request from an application is processed in transaction units. Therefore, the update processing for the original data is also executed in units of the update TR, and the update processing (replication data) in the replica site is reflected in the replica data in units of the update TR that caused the update.

(Main Purpose of the System) The main purpose of the system is to keep the database (lexicon set) the same on a plurality of machines. That is, each machine holds a copy of the database having the same contents, and when an update is made to the database by one machine, the update information (content) is transmitted to each machine via the communication network. The goal is to achieve this by communicating and promptly updating the database in each machine. In this specification, this function is called "replication".

In this specification, a machine having a right to update a database is called an original site of the database, and its data is called original data.
Other machines holding a copy of the database are called replica sites, and the data is called replica data.

Further, the present system has a function of executing a transaction (update TR) for updating the database at the above-mentioned original site. In addition to the above-mentioned replication, a database consisting of a plurality of copies is logically transmitted from the application of each machine. Operate so that it looks like a single database. That is, the application on each machine does not need to care which machine the original site is. In this specification, such a system configuration is called a “remote / local structure”.

Further, in the present system, until the execution of the transaction and the reflection of the replication data have been completed by one unit, the processing of other transactions that operate on the database (rekin console set) is not performed (of course, other transactions are not performed). It does not reflect replication data.) If the execution and reflection of those transactions, or the execution of other transactions or the reflection of replication data for the database (reconconset) is in progress, the processing is started after the completion thereof. In other words, the execution of a transaction relating to one database (of one machine) and the reflection of replication data are serially processed in transaction units. Therefore, the transaction and the application requesting the execution do not access the contents of the database during execution of another transaction.

It should be noted that a transaction that does not perform an update operation but only retrieves and references data is called a reference transaction with respect to an update transaction. In this system, the replication function quickly matches the original data with the replica data in transaction units. Therefore, the reference transaction has no inconvenience even if the replica data of the machine (local machine) requested for the transaction is operated. Does not occur.

Further, the communication network is a means for the original site to transmit the replication to the replica site to realize the replication function, and at the same time, to transfer the update transaction issued (requested) at the replica site to the original site. It is also a means. The function of executing the update transaction only at the original site is specifically realized by transferring the update transaction issued at the replica site via the communication network to the original site. [2. Explanation of Terms] Before describing each embodiment,
Various terms used in this specification will be described.

(1) Unispace (shared unit area / database execution unit area) This system cooperates on a plurality of machines (hosts) connected by a network to consistently share shared data on a main memory. In this system, the unispace distinguishes data shared between a plurality of machines (hosts) constituting the system and a data access (reference / update) service. Is an identifier for This identifier is used to identify a group in which servers communicate with each other. It is also used when an application requests a service for accessing shared data from each server. The unispace identifier is composed of a set of an ASCII character string representing the name of the unispace and an IP multicast address used for inter-group communication.

(2) Lexicon set A lexicon set is defined by defining a subset of the shared data constituting the unispace. It is possible to specify whether or not to arrange data for each lexicon set for each machine constituting the main storage area. In the present system, the main storage data can be backed up and saved in a file, but also in the lexicon set unit.

The lexicon set has an index function as a database that enables high-speed access to shared data. The basic data structure is described below. (a) Lexicon: A subset of the Lexicon set. Belongs to the lexicon set. (b) Cell (CELL): An array for storing data. It has attributes of type (data type), capacity (length of array), and count (effective length as a key at the time of sorting). Belongs to lexicon. (c) Context (CONTEXT): Data (array of cells) that gives a linear relationship to cells. Has a capacity attribute. Belongs to lexicon. (d) ROW: Data that specifies a sort key for a part of the context. It has low-length and key-length attributes. Belongs to the context. (e) Facade (FACADE): Data that allows rows to be sorted and searched. The core of the index function.
Belongs to lexicon.

(3) Transaction A transaction refers to an operation for consistently referring to and updating shared data in response to a request from an application participating in the Unispace service. The set of data that a transaction can operate on at one time is only one lexicon set. In this system, when updating shared data using a transaction, after updating at a specific site where original data exists (hereinafter referred to as a base site or an original site), the update result is updated to another site constituting the same Unispace. Data consistency is maintained by multicasting (hereinafter referred to as replication). This base site can be specified for each lexicon set. In this system, transactions issued by applications are classified into three types: (a) local reference, (b) local update, and (c) remote update.

(A) Local Reference In the case where the transaction operation is only reference to shared data, it is processed as an access to completely local main storage data, and no network traffic occurs. In other words, since the data is only referenced by executing the transaction and is not changed at all, regardless of whether the own site is the original site or the replica site, by always accessing the main storage data of the own site, Transaction execution processing is performed.

(B) Local Update The case where the site where the application that issued the transaction exists is the original site. In other words, you can update the data at your own site, and after updating, by multicasting the update data to other sites,
This is a function that always enables the same data to be used by each host.

(C) Remote update When the site where the application that issued the transaction exists is a replica site. In other words, since the data at the own site is replica data, the data cannot be updated, so the transaction is transferred to the original site, and after updating the data at the original site, the updated data is received by replication. A function that enables the use of the same data. If the own site is a replica site and there is no application that issued the transaction, the update data replicated from the original site is reflected in the own site,
The same data is always available for each host.

The distinction between the local update of (b) and the remote update of (c) is made depending on whether or not the base site is the same as the transaction reception site. In the case of (b) local update, the timing of updating the local main memory data, and in the case of (c) remote update, transfer the transaction to the base site and update the shared data, then receive the replication and update the local data It ends at the timing of doing. The distinction between the local update and the remote update is performed within the system, and the application is unaware of this.

(5) Retrieval Retrieval is a function of making original data or replica data usable as set when the system is started or when lexicon set data is stored in the main memory. Receive all lexicon set data from other hosts (either original or replica) via the network.

Also, a list of hosts to which a retrieve request is sent can be specified. Send a transmission request to the hosts in the host list according to a certain rule.
Original and replica placement, network bandwidth,
By determining the host list according to the specifications of the machine, settings suitable for the system configuration can be obtained. In general, data is allocated to each host via a network, but when the system starts up,
When the retrieval from the network fails, loading from a file is possible, and loading from a file before performing the network retrieval is also possible.

(6) Replication The replication is a function of transmitting a data change by an update transaction to another machine by multicast. Execute the update transaction on the original and send only the update to the replica by multicast. The replica receives it and reflects it in the replica data.

(7) Backup The backup is a function of storing the contents of the lexicon set in the secondary storage device. Whether to back up to the secondary storage can be specified as an option (because it is configured to be able to be specified as appropriate), and a system configuration that can flexibly cope with required throughput and improved reliability can be taken. . The data saved by the backup function is used by the retrieval function at the time of startup or recovery from a failure. Since the backup processing to the secondary storage device is performed asynchronously with the transaction processing, the throughput of the transaction processing is not reduced, and the high-speed main storage data management can be maintained.

(8) Terms relating to sites constituting a network Local site: own site Remote site: other site Original site: site having original data Replica site: holding replica data (copy) Site

[3. Next, the configuration of each host will be described with reference to FIG. As described in the overall configuration diagram, the database management system 1 is disposed in the main storage area of each host. The management system 1 includes a plurality of processing units or setting units, and a database called a lexicon set 2 for reflecting these processes and settings. The system also includes a transaction accepting unit 3 serving as a contact point (contact point) with a system management application and a business application, and a transmitting unit and receiving units 4 and 5 for connecting each host to a network.

The following are prepared as a plurality of processing units and setting units provided in this management system. (1) System Configuration Setting Unit 11 The system configuration setting unit 11
11, backup host setting unit 112, lexicon definition unit 113, and multicast address setting unit 114
It has. Among them, the base host setting unit 111
Defines whether to place the original data on any of a plurality of hosts, that is, on which host on the network the base (original) of a certain lexicon set is placed. The backup host setting unit 112 arranges such that one or more backup hosts exist for each base host while the system is operating. The lexicon definition unit 113 determines, for the lexicon set defined by the base host setting unit 111, a lexicon belonging to the lexicon. The multicast address setting unit 114 sets a default multicast address as a parameter at the time of system startup or a multicast address different from the default for each lexicon set.

(2) Transaction Management Unit 12A The transaction management unit 12A defines a transaction used by an application and a transaction function executed by this transaction.
Defines the relationship with the lexicon set accessed by this transaction function. In addition, processing such as reference, update, and search of data in the lexicon set is performed using a transaction. This transaction management unit 12A
Will be described in detail with reference to FIG.

(3) Transaction processing unit 12B The transaction processing unit 12B selects a transaction function corresponding to the transaction when an application requests execution of the transaction in accordance with the setting of the transaction management unit 12A. Using this transaction function, processing such as reference, update, and search of data in the lexicon set is performed.

(4) Data resident management unit 13 The data resident management unit 13 determines in advance which lexicon set is to be resident in each host, that is, which lexicon set can be accessed by the business application of each host. Perform the setting process. Also,
When the system is running, the base host retrieves the required data from each replica site, retrieves new sets of lexicons on a given host,
It also performs resident status change processing such as releasing resident status.

(5) Replication Processing Unit 14 The replication processing unit 14 performs a replication process for ensuring data consistency between the base host and the replica site set in advance in the system configuration setting unit. That is, access to the data performed by the business application is performed via a transaction. In this transaction, as described in the description of the term, “reference” that only refers to data, and “data is changed” There are two types of processing of "update". Also, there are two types of hosts that execute the TR, namely, "local site... Own site" and "remote site... Other site". Therefore, the replication processing unit 14 performs the following processing described in the description of the term according to these types. (a) Local reference processing (b) Local update processing (c) Remote update processing

(6) Base host switching processing unit 15 As set in the system configuration setting unit 11, the base host is set in advance for each lexicon set, and the system is operated in accordance therewith.
However, it may be necessary to switch the base host of the lexicon set to another host for reasons such as failure of each host connected on the network, maintenance and inspection, and network failure. In this case, each host connected on the network has the following three positions. In other words, (a) a host that is currently the Base host (old Base host), (b) a host that will become the next Base host (new Base host), and (c) a host other than the above two types (another host). is there. This base host switching processing unit 15
The above three types of hosts are used to replicate the original data from the old base host to the new base host or another host, and to communicate between the hosts which base host after the switching is the host. Perform processing.

[4. System Configuration Setting FIG. 3] For each host as shown in FIG. 2, in this embodiment, various settings are made as follows. This setting is performed when the registration transaction requested to be executed by the system management application accesses each setting unit and processing unit. That is, the present system uses the main storage area of each host (in this embodiment, Unispace / Unis
In this example, the main storage area is correctly initialized in advance in the following example since the data called a lexicon set and data related to a transaction for performing various processing on the data are placed on the main storage area. It is assumed that it is done.

In order to operate the present system, each data is allocated to the main storage area initialized as described above, and various settings are made for each data.
For that purpose, a dedicated system management application is used. The registration of a transaction is also performed from the application. However, since the application performing the transaction request and the application performing the transaction registration use different applications, the types of the applications are different. Therefore, in the present embodiment, an application for performing system settings such as transaction registration is referred to as a “system management application”, and an application for requesting execution of a transaction is referred to as a “user execution application”.

(1) Definition of lexicon set (S030)
1) The user needs to define a lexicon set determined at the time of design. That is, the transaction accepting unit 3 accepts a transaction issued from the system management application, and in response to a command from the transaction accepting unit 3, the base host setting unit 111 provided in the system configuration setting unit 11 of FIG. Specify the host. The following example defines the "real name" of the lexicon set to be defined for the main storage area called Unispace, and the host on the network where the base (original) of this lexicon set is to be placed. That is, a lexicon set called “SampleLexiconSet” is defined by the base host “host_1”. DefineLexiconSet (& us, "SampleLexiconSet", "host_1"); However, in this state, only the lexicon set is defined, and there is no actual data.

(2) Definition of backup host (S03)
02) That is, the backup host setting unit 112 provided in the system configuration setting unit 11 allows the user to define one or more backup hosts for each lexicon set. At this time, the user always defines one or more backup hosts. Arrange so that one or more backup hosts exist.
In addition, the backup host setting unit 112 determines whether or not to back up a file in each backup host. For example, host1 and host2 are the backup hosts of SampleLexiconSet, and the file Backup
However, if the file is not backed up on host2, it is as follows. SetLexiconSetBackupHost (& us, "SampleLexiconSet", "ho
st1 ", TRUE); SetLexiconSetBackupHost (&us," SampleLexiconSet "," ho
st2 ", FALSE);

(3) Definition of Lexicon (S0303) Next, the lexicon definition unit 113 defines a lexicon belonging to the lexicon set in the lexicon set defined as described above. In this case, in the present embodiment, the lexicon to be defined is defined together with the lexicon set to which the lexicon belongs, together with the type of whether the lexicon is single-original or multi-original.
Here, the single original lexicon can be updated (create / change cell / context etc.) only on the base host of the lexicon set. For hosts other than the base host, the result of the update operation on the base host is replicated and reflected in the lexicon contents. With a multi-original lexicon, update operations are possible on any host. The result of the update operation is not replicated and the update result remains local. That is, "Sampl
Two lexicons "Lexicon_1" and "Le" in "eLexiconSet"
xicon_2 ". Define" Lexicon1 "as a single original and" Lexicon2 "as a multi-original. DefineLexiconInLexiconSet (&us," SampleLexiconSet ","
Lexicon1 ", SingleORG); DefineLexiconInLexiconSet (&us," SampleLexiconSet ","
Lexicon2 ", MultiORG);

(4) Definition of Transaction Library (S0304, S0305) In the present system, transaction functions and transactions have a one-to-one correspondence, and the transaction management unit 12A defines a set of transactions as a library. Register the library in the lexicon set. For example, set the transaction library "TRLIB" to the lexicon set "SampleLexiconSet"
Defined in The library has three transactions "tr
1 "," tr2 "," tr3 "char * TrNames [3]; TrNames [0] =" tr1 "; TrNames [1] =" tr2 "; TrNames [2] =" tr
3 "; DefineTransactionLibrary (&us," SampleLexiconSet "," T
RLIB ", 3, TrNames); Although the transaction is defined in this way, there is no transactional entity that can be executed yet.

(5) Associating Transaction Name with Transaction Function Name (S0306) The transaction management unit 12A associates a transaction name with a transaction function name. At the same time, the lexicon to be accessed by the transaction and the access mode are determined, and registered in the lexicon set in association with the transaction. At this point, it is set to which lexicon the transaction is accessed. Here, the access mode indicates reference or update. In the case of reference, the transaction is only allowed to refer to the contents of the lexicon, and it is impossible to rewrite the contents of the lexicon. In the case of updating, it is possible to refer to the contents of the lexicon or to rewrite the contents. For example, three transactions "tr1", "tr2", "tr
3 "is the transaction function" tr1all "," tr2sr "respectively
h "," tr3upd ", where" tr1 "is the lexicon" Lex
icon1 "," Lexicon2 "is updated," tr2 "refers only to" Lexicon1 "," tr3 "updates" Lexicon1 ", and refers to" Lexicon2 "as follows: char * lex [ 2]; int mode [2]; lex [0] = "Lexicon1"; lex [1] = "Lexicon2"; mode [0] = TRUE; mode [1] = TRUE; AttachTransactionToFunction (& us, "SampleLexiconSe
t "," tr1 "," tr1all ", 2, lex, mode); lex [0] =" Lexicon1 "; mode [0] = FALSE; AttachTransactionToFunction (&us," SampleLexiconSe
t "," tr2 "," tr2srh ", 1, lex, mode); lex [0] =" Lexicon1 "; lex [1] =" Lexicon2 "; mode [0] = TRUE; mode [1] = FALSE; AttachTransactionToFunction (& us, "SampleLexiconSe
t "," tr3 "," tr3upd ", 2, lex, mode); In this case, only the transaction name is associated with the transaction function name, and the transaction is not yet executable.

(6) Definition of lexicon arrangement (S030)
7) The data resident management unit 13 defines a host on which the lexicon is located. Placing only the lexicons needed for transactions running on each host saves the most resources. If there is room in the computer, each host may have the same arrangement status. For example, the lexicon set "SampleLe
"Lexicon1" and "Lexicon2" of "xiconSet" host "host1"
When it is arranged in the following, it is as follows. . DefineHostOfLexiconResidence (& us, "SampleLexiconSe
t "," Lexicon1 "," host1 "); DefineHostOfLexiconResidence (&us," SampleLexiconSe
t "," Lexicon2 "," host1 "); In this state, only the host where the lexicon is placed is defined, and the main storage area where the lexicon data is actually placed or the lexicon data is stored is secured. The data is actually allocated and the main storage area is secured when the lexicon set data is made resident.

(7) Transaction library and DLL
Loading the File (S0308) Next, the transaction management unit 12A associates the DLL file in which the transaction function is made into a library with the transaction library and loads the DLL file on the host on which the present system storing the lexicon set is running. Only the transaction that can be associated with the transaction function name at the time of loading is linked with the transaction function pointer. For every transaction in the transaction library, find the association of the transaction function name and load it
The transaction function pointer is found and linked from the DLL file using the transaction function name.
For example, for transaction library "TRLIB", DLL file "c: \ gigabase \ trfun" on host "host1"
When loading c.dll ", the file type is DLL. LoadTransactionLibraryFile (&us," SampleLexiconSe
t "," TRLIB "," host1 "," c: \ gigabase \ trfunc.dll ", DLL);

Here, the transaction and the function pointer are linked for the first time, but in order for the transaction to be actually executed, the lexicon set of the executed transaction must be resident in the host where the transaction is executed. At this point, the transaction function has been loaded into the system, and the association between the transaction and the transaction function has been completed. By registering a transaction in the present system in this way, the transaction function is executed on the present system, and the database can be operated in the present system.

(8) Definition of lexicon set alias (S0
309) Further, in the transaction processing unit 12B, when the execution of the transaction is thrown from the application, the transaction processing unit 12B can specify and execute the lexicon set alias. If you want to run a transaction under a lexicon set alias,
Define an alias before executing the transaction. For example, the lexicon set "SampleLexiconSet" has the alias "ALIA
To define "S": DefineLexiconSetAlias (& us, "SampleLexiconSet", "ALIA
When throwing a transaction from the application, it is thrown not only in "SampleLexiconSet" but also in "ALIAS." In this embodiment, the system management application is configured so that the lexicon set alias cannot be used.

(9) Setting of multicast address (S
[0310] If this setting is not performed, communication relating to the user-defined lexicon set is performed using the default multicast address set in the system startup parameters. Therefore, when this setting is performed by the multicast address setting unit 114 in the system configuration setting unit 11, communication is performed with a multicast address different from the default. Set this when performing lexicon set communication with a multicast address different from the default multicast address. To make lexicon set data communicate with the set multicast address, lexicon set data must be resident after this setting. If the lexicon set data is resident before the multicast address is set in a certain host, the multicast address is not changed because data has already been transmitted and received. In this case, once the lexicon set data is made non-resident and is made to reside again, the set multicast address becomes valid. For example, the multicast address 2 in "SampleLexiconSet"
When setting 32.122.32.93, it is as follows. unsigned int maddr; maddr = (232 << 24) + (122 <16) + (32 << 8) +93; SetMulticastAddressForLexiconSet (& us, "SampleLexico
nSet ", maddr);

(11) Resident of lexicon set (S03
11) The resident of the lexicon set in each host by the data resident management unit 13 allows the user to load data into the main storage area and execute the transaction function. When making this setting, you must specify where to get the lexicon set data. This is the retrieve request destination host. If this system is not running on the host where the lexicon set is to be resident, the actual resident operation of the lexicon set data, that is, the retrieval, does not move, but only the resident information is defined. In this case, the actual operation of the retrieve is the next time the present system is started.

That is, in the resident operation of the lexicon set, if the present system has been started, data retrieval is performed. When the lexicon set data is retrieved, the TR that has been linked at that time can be executed. Once the lexicon set data has been retrieved,
If set, the multicast address can be used. When the lexicon set is retrieved, only the lexicon whose arrangement is defined by the host at that time is stored in the main memory.
For example, when lexicon set "SampleLexiconSet" is placed on host "host1". At that time, the host that requests the retrieval is "host2", "host3". char * rethost [2]; rethost [0] = "host2"; rethost [1] = "host3"; LoadLexiconSetData (& us, "SampleLexiconSet", "host1",
2, rethost);

[5. Execution Procedure of Application and Transaction Function: FIG. 4] FIGS. 4 and 7 show a processing flow in which a transaction function is called from an application to execute a series of processing. (1) The application first connects to this system (S0401). (2) The application secures a shared memory for exchanging data with this system (S040
2). (3) The application sets the input parameters to be passed to the transaction function in the shared memory (S040)
3). (4) The application issues a transaction execution request to the present system (S0404). (5) The application waits for execution until the processing of the transaction function ends (S0405). (6) Upon receiving a transaction execution request from the application, the system activates the specified transaction function (S0406). That is, as shown in FIG. 7, when an application requests execution of a transaction corresponding to a process when the application attempts to execute the application, a transaction function corresponding to the transaction on a one-to-one basis is selected, and the transaction function is activated. Is done. (7) When activated, the transaction function first retrieves parameters necessary for processing from the application from the shared memory (S0407). (8) Next, the transaction function accesses the database, such as referencing, searching, updating, deleting, and adding. Process the transaction function using this data,
Data required as output is created (S0408). In this case, the transaction function performs necessary processing on the lexicon of the lexicon set registered in advance by the system management application. (9) The transaction function sets the created data in the shared memory (S0409). (10) The transaction function ends the processing (S04)
10). (11) When the processing of the transaction function ends, the present system notifies the application of a transaction end notification (S0411). (12) Upon receiving the end notification, the application reads the processing result of the transaction function from the shared memory (S0412). (13) The application releases the shared memory (S0
413). (14) The application executes disconnection from the present system when a series of processing is completed and access to the present system becomes unnecessary (S0414). (15) The application ends (END).

[6. Execution of Reference Transaction and Update Transaction] At the time of execution of the above-described transaction, the type of transaction requested by the user application, that is, access to the database in step S0408 in FIG. 4 such as reference, search, update, deletion, addition, etc. The processing in this system differs depending on the mode as follows.

(1) Reference Transaction If the transaction is a reference transaction that does not modify the database, the transaction processing unit 12B causes the lexicon to be accessed to execute the transaction. Then, after the execution of the transaction is completed, the execution result is notified to the application. This reference transaction can be executed at each site irrespective of whether the data in the host is the original data or the replica data, since the data is not rewritten only by referring to the data.

(2) Update Transaction In the case of an update transaction, the processing differs depending on whether the host requesting execution has original data (hereinafter, the original side) or has replica data (hereinafter, the replica side). First, in the case of having the original data, the transaction processing unit 12B like the reference transaction
Causes the lexicon to be accessed to execute the transaction and notifies the application of the execution result. If you have replica data, you cannot directly update the lexicon in a transaction. Therefore, the transaction processing unit 12B of the base site is connected to the transaction processing unit 12B of the base host via the network.
Submit a transaction to. The transaction processing unit 12B of the base host executes a transaction stored in the base host and updates the lexicon of the original data. When the original data is updated, the updated data is replicated to the replica site, and the data at the replica site is updated. When the data at the replica site is updated, the transaction at the replica site notifies the application of the execution result to the application.

[7. Settings Related to Transaction] To execute such a system, it is necessary to set the following system configuration. The setting of the system configuration is generally performed by a program called a system management application. (1) Lexicon set name and its base host (candidate to switch) (2) Lexicon set and its included lexicon (3) Transaction library and its included transactions (4) Transaction name and its necessary to execute this transaction Transaction function (5) Lexicon accessed by transaction and its access form (reference / update) (6) Alias of lexicon set (if necessary) (7) Multicast address of replication transmission performed to reflect lexicon set to each host (If necessary) (8) Lexicon set to be resident on each host (9) Lexicon to be placed on each host (included in resident lexicon set) (10) Transaction library to be loaded on each host and DLL file name (11) Each lexicon The presence or absence of the door of the backup host and each file backup

[8. Configuration of Transaction Management Unit 12A FIG. 5] An embodiment of a configuration of a system for performing the above-described transaction-related settings will be described below with reference to a functional block diagram shown in FIG. That is, the transaction management unit 12A of the present embodiment includes the transaction registration management unit 401 that manages the registration of the transaction at the own site. The transaction registration management unit 401 includes a transaction storage unit 402 in which transactions for executing various processes requested by the application are stored, and a library for grouping prepared transactions in accordance with a database to be processed. Registration unit 403, lexicon access mode setting unit 404, and transaction
A transaction function association unit 405 is provided.

The library registration unit 403 defines the transaction library described in steps S0304 and S0305 in FIG. 3. For example, the library registration unit 403 creates a transaction-library correspondence table 503 as shown below, and Are defined as a library 502, and the library 502 is registered in the lexicon set 2 to be processed.

[Table 1]

The lexicon access mode setting unit 404
The lexicon to be accessed and the access form of the transaction described in step S0306 of FIG. 3 are registered. As an example, the following transaction-lexicon correspondence table 504 is created.

[Table 2]

The transaction-transaction function associating unit 405 associates the transaction name described in step S0306 of FIG. 3 with the transaction function name, and creates the following transaction-transaction function correspondence table 505 as an example.

[Table 3]

The transaction management unit 12A includes:
A DLL file 406 in which a transaction function is made into a library and a DLL load unit 407 that performs processing for loading the DLL file 406 into its execution area are provided. The DLL load unit 407 includes a DL
L storage processing unit 408 and library-DLL association unit 4
09 is provided. That is, the DLL storage processing unit 4
08 is for loading the contents of the DLL file 406 into the transaction program storage area 508 and notifying the location stored in the library-DLL association unit 409.

The library-DLL associating unit 409
As described in step S0308 of FIG. 3, the DLL file 406 in which the transaction functions are libraryd is associated with the transaction library 502 and registered in the lexicon set 2 to be accessed. That is, the library-DLL associating unit 409 associates the library name of the transaction with the storage location of the DLL file obtained by the DLL storage processing unit 408. For example, the library-DLL associating table 509 as follows: Record.

[Table 4]

Further, the transaction registration management section 401 is provided with an alias registration section 410 for registering an alias of a lexicon set. This alias registration part 4
Numeral 10 executes step S0309 in FIG. 3, and enables an application to specify a lexicon set alias when executing a transaction from an application.

[9. Operation of Transaction Registration Management Unit: FIG. 6] Hereinafter, the setting processing of each of these transactions will be specifically described with reference to the flowchart shown in FIG.

First, when an execution request for a system management transaction is issued from the system management application, the transaction reception unit 3 receives the execution request and activates the transaction registration management unit 401. Then, the registration management unit 401 first selects a transaction to be used when executing the user application from a plurality of transactions stored in the transaction storage unit 402, and groups them as a library 502 (S0601). The library 502 of transactions grouped in this way is registered in the lexicon set 2 to be accessed by the user application (S
0602). At this point, the transaction-library correspondence table 503 is created.
03, for example, each of the transactions TR1, TR2,... Belongs to which library LibraryA, LibraryB, and the library LibraryA, LibraryB
Whether it is registered in LexiconSetA or LexiconSetB is recorded. In this case, the required transaction may differ depending on the type of user application used on the computer. Therefore, a plurality of libraries 502 corresponding to various applications are prepared.
By registering this in the database (lexicon set) accessed by each application, it is possible to prepare in advance the transactions required for each application.

Next, one transaction registered in the library 502 is selected (S0603), and an access mode is set for this transaction and the lexicon to be accessed (S0604). That is, in the present embodiment, the library itself is
The transaction is registered in the lexicon set to be accessed. For each transaction included in the library, the transaction is registered in the lexicon to be processed. For example, when the transaction TR1 in each of the above tables is selected, the lexicon Lexicon1 to be accessed and the access mode “reference” for the lexicon Lexicon1 are registered.

Subsequently, the transaction TR1 is associated with the transaction function TRFunc1 corresponding to the transaction on a one-to-one basis (S0605).
Register it in xiconSetA (S0606). by this,
The transaction-lexicon correspondence table 504 and the transaction-transaction function correspondence table 505
(Transaction TR1 part of the table) is created. In this way, it is verified whether or not the registration has been completed for all the transactions (S0607).
4 and 505 are completed.

In this system, transactions and transaction functions are associated with each other on a one-to-one basis. However, since the processing executed by the application is classified according to the viewpoint of the user who uses the application, the viewpoint of data processing is considered. When viewed from the above, many of the processes are configured by a plurality of processes. Thus, by arranging common parts for various processes required by the application, it is possible to set a transaction suitable for data processing and a transaction function corresponding to the transaction. For example, if the process A viewed from the user side is composed of processes a, b, and c from the viewpoint of data side access, and the other process B is composed of processes a, d, and e, (Process a), (Process b + Process c), (Process d +
If the processing unit is composed of three processing units, ie, processing e), and these processing units are transactions x, y, and z, the processing A can be realized by the transaction x + y and the processing B can be realized by the transaction x + z. Therefore, in the present system, each of the transaction transactions x,
If y and z are registered as transaction functions, it can be reused in this unit.

After the association between the transaction and the transaction function is completed as described above, the DLL
The DLL file is loaded into the transaction program storage area 508 by the DLL storage processing section 408 of the load section 407 (S0608), and the storage location of the DLL file in the transaction program storage area 508 is associated with the transaction library (S0609). . That is, only the transaction associated with the transaction function name at the time of loading this DLL file is linked with the transaction function pointer. Transactions that are not associated with a transaction function name are not linked with function pointers. A transaction function name association is found for all the transactions in the transaction library, and a transaction function pointer is found and linked from the loaded DLL file using the transaction function name. As a result, the transaction function is loaded into the system, and the association between the transaction and the transaction function is completed. By registering a transaction in the present system in this way, the transaction function is executed on the present system, and the database can be operated in the present system.

In this system, even if a new transaction name is associated with a transaction function name after the DLL file has been loaded, the transaction is not linked to the transaction function pointer. Further, even if the association between the transaction name and the transaction function name is changed, the change does not extend to the change of the transaction function pointer. In this case, once the DLL file is unloaded, all the transaction links in the transaction library are deleted, and the DLL file is loaded again, the transaction is transferred to the transaction by associating the new transaction name with the transaction function name. Function pointers are linked. This is because the association between the transaction name and the transaction function name is a plan for linking with the transaction function pointer. The execution of the link is performed by loading the DLL file. Since the plan is activated by the load, the load must be redone for the changed plan to take effect.

As described above with reference to FIGS. 5 and 6, in the state where various settings relating to the transaction have been made by the system management application, as shown in FIG. Transaction function
The lexicon set to be accessed by the transaction function, the lexicon, and the access form of reference / update to the lexicon set are set.

When the user application is executed in a state where such a setting process has been performed, and a transaction execution request is issued from the user application, the transaction processing unit performs processing in accordance with the contents of various correspondence tables registered in advance. , FIG. 9, FIG. 10, and FIG. That is, FIG. 9 shows a case where the requested processing is a reference transaction. Since this reference transaction does not involve data modification as described above, it is possible to directly execute the transaction even if the database is the original lexicon set or the replica lexicon set.

When the requested process is an update transaction, the process differs depending on whether the host where the application is located is the base host of the lexicon set to be updated or the replica site. FIG. 10 shows a case where the host where the application is located is the base host of the lexicon to be updated. in this case,
For the lexicon in the lexicon set of the host,
The update process can be directly performed and the execution result can be obtained.

On the other hand, FIG. 11 shows a case where the host on which the application is located is a replica site. In this case, the data of the replica is not directly updated, and the original data is updated with respect to the base host. Ask for. Then, an execution result is obtained by a method of reflecting the update result of the original data on the replica site by replication.

[11. Alias registration process] As described above,
In this embodiment, when an application requests execution of a transaction, a lexicon set to be executed is specified. In this case, it is possible to register not only the name (real name) at the time of defining the lexicon set but also an alias as a method of specifying the lexicon set. Therefore, an alias can be defined in the lexicon set and a transaction can be requested by that name.

For example, a lexicon set having a real name LexiconSet_A is given an alias Online. Meanwhile, the real name Lexic
Give the lexicon set onSet_B the alias Maintainance.

[Table 5]

In such a setting state, as applications for operating data, there are an application group X operating in a normal operation state and an application Y for data construction. When requesting the execution of a transaction, the application group X operating in the normal operation state always specifies the lexicon set as Online. When requesting the execution of a transaction, the application group Y for data construction always specifies the lexicon set as Maintainance. And LexiconSet
It is assumed that a transaction used in the application group X and a transaction used in the application group Y are registered in both _A and LexiconSet_B.

[Table 6]

At this time, the application group X is executed on LexiconSet_A according to the aliasing method at this time. The application group Y is executed on LexiconSet_B. Now, if the data construction in LexiconSet_B (Maintainance) is completed and it is desired to operate the application group X operating in the normal operation state with new data, the aliases may be exchanged.

[Table 7]

When the aliases are exchanged, the transaction of the application group X is naturally executed on LexiconSet_B, and the application group Y is executed on LexiconSet_A. Thus, without changing the application
The lexicon set to be operated can be changed.

[12. Effect of Embodiment] As described above, according to the present embodiment, various settings can be made in advance for a transaction.
The following functions and effects are exhibited.

(1) Since a plurality of identifiers can be registered or deleted in the form of “alias” in one database, processing as a transaction for another database is performed without changing the database designation identifier of the transaction issued by the application. Can be. That is, the database to be accessed can be easily switched.

(2) Lexicon set (database)
By checking the reference / update for each lexicon (part) that constitutes the lexicon, not for the whole, it is possible to determine that the original site is different depending on the lexicon or that the transaction for updating the multi-original data (lexicon) is local.

(3) By associating a library (or a plurality) with a lexicon set and associating a DLL file with each site not with each transaction, even if the configuration content of the DLL file differs with each site, efficiently. You can link a transaction function name with a program.

[13. Other Embodiments] (1) In the description of the embodiments, all execution of a transaction has been described as calling a transaction function, but the form of execution of a transaction is not limited to this. For example, each transaction includes a description of a specific data operation procedure, and the present system may interpret and execute it according to a certain procedure.

(2) In the description of the embodiment, “a plurality of machines” are assumed to be physically different machines, and the communication network is assumed to be a communication means including a physical medium between them. The present invention may be applied to a machine, for example, a different process in the same machine. In this case, different means (process IDs, etc.) may be used for identifying each (logical) machine. The database (lexicon set) managed by this system is
One or more may be used.

(3) A communication network as a means for transmitting replication data and a communication network as a means for transferring a transaction are different even if the same one is physically / logically used. May be used. It is often efficient to use a multicast / broadcast network to transmit to multiple replica sites, but the practice of the present invention is not so limited. On the other hand, one-to-one communication is usually sufficient for transaction transfer. However, if a site that should not be executed is received, multicast / broadcast is performed under the condition that such site is not executed or discarded at the discretion of that site. It is also possible to employ a network.

(4) As described above, a transaction includes an identifier (transaction name or the like) for giving various attributes. For example, a transaction function to be executed is associated with this identifier. The identifier may be set to a required number according to the type of attribute to be assigned. The target of a transaction is one lexicon set. In the above embodiment, since the Unispace can include a plurality of lexicon sets, the transaction specifies the lexicon set to be operated. This lexicon set name may be considered as one of the above identifiers. Of course, an embodiment in which a means for determining the lexicon set to be operated from another identifier is also possible, and it is not essential to specify the lexicon set name.

[0109]

As described above, according to the present invention,
It is possible to provide a transaction-type database system that exhibits excellent effects as described below.

(1) Flexibility by Remote / Local Structure The distributed system provided by the present invention is a system called a remote / local structure that does not depend on the hardware configuration of the system. Since application software does not need to implement the hardware configuration of the system, software development can be made independent of system construction. Therefore, no coding for system construction is required, and all system construction / setting operations can be performed using the system operation environment.

The remote / local structure makes the application software independent of the computer hardware configuration. Therefore, the application does not need to be conscious of the system physical structure, that is, the physical configuration of the hardware, the computer on which the data is mounted, or the data consistency. Therefore, the user can concentrate on the design and implementation of the business logic, and the development productivity is improved. As described above, according to the present invention, an application developer can develop an application without being conscious of remote execution and local execution, so that the application is simplified and productivity is increased.

(2) Improvement of Productivity by Transaction Function In the present invention, access to data from an application is performed through a transaction function. That is, data encapsulation is realized by the transaction function. In data encapsulation, since a change in the data structure does not propagate to the application, a transaction for performing data operations can be made into components. In particular, since the present invention has a system configuration of a remote / local structure, the transaction function does not include any implementation related to the system. Therefore, parts having high independence can be obtained, and reusability is further improved. By reusing transaction functions, development productivity is remarkably improved.

(3) Function Change without System Stop The system setting of the present invention can be dynamically changed for functions such as a change in data structure and addition of a transaction function. Therefore, these functions can be changed without stopping the system,
It is very easy to respond to changes in system settings. For example, an application need only be aware of the transaction name because the transaction function corresponding to the transaction can be freely changed. Also, by giving the transaction an access right to the data in advance, it is possible to prevent erroneous operation of the data by the application. The ability to switch functions without stopping the system in this way means "improving maintainability"
The effect is “easiness of changing the system settings”.

[Brief description of the drawings]

FIG. 1 is a functional block diagram showing an overall configuration of a transaction processing type database system of the present invention.

FIG. 2 is a block diagram illustrating a configuration of each host in the database system of FIG. 1;

FIG. 3 is a flowchart showing a setting order of a system configuration in the database system of FIG. 1;

FIG. 4 is a flowchart showing an execution procedure of an application and a transaction function in the database system of FIG. 1;

FIG. 5 is a block diagram illustrating a configuration of a transaction management unit in the database system of FIG. 1;

FIG. 6 is a flowchart illustrating an operation of the transaction management unit in FIG. 5;

FIG. 7 is a block diagram showing processing when a transaction is requested by an application.

FIG. 8 is a block diagram showing various setting states of a transaction by a system management application.

FIG. 9 is a block diagram illustrating an execution state of a reference transaction.

FIG. 10 is a block diagram showing an execution state of an update transaction for original data of a base host.

FIG. 11 is a block diagram illustrating an execution state of an update transaction for replica data at a replica site.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 1 ... Database management system 2 ... Lexicon set 21 ... Lexicon 3 ... Transaction reception part 4 ... Transmission part 5 ... Reception part 11 ... System configuration setting part 12A ... Transaction management part 12B ... Transaction processing part 13 ... Data resident management part 14 ... Replication Processing unit 15 base host switching unit 401 transaction registration management unit 402 transaction storage unit 403 library registration unit 404 lexicon access mode setting unit 405 transaction-transaction function association unit 406 DLL file 407 DLL loading unit 408 DLL storage processing unit 409: library-DLL association unit 410: lexicon set alias registration unit 502: library 503: transaction-library correspondence table 50 ... Transactions - lexicon correspondence table 505 ... transactions - transaction function correspondence table 508 ... transaction program storage area 509 ... libraries -DLL correspondence table

 ──────────────────────────────────────────────────続 き Continued on the front page F-term (reference) 5B082 GB00 5B085 AA08 BA07 BG03 BG07

Claims (9)

[Claims] A transaction processing unit configured to execute processing on the database; a transaction management unit configured to manage a transaction executed by the transaction processing unit; The management unit prepares a transaction function necessary to execute each transaction, and when the transaction is issued, selects a transaction function corresponding to the issued transaction, and uses this transaction function. A transaction processing type database system for executing processing on a database. 2. A database arranged in a main storage area of a computer, a transaction processing unit for executing a process for the database, and a transaction management unit for managing a transaction executed by the transaction processing unit. The transaction management unit includes a transaction registration management unit for preselecting a transaction function corresponding to a transaction to be executed, and a transaction function loading unit for loading the selected transaction function and performing processing on the database. A transaction processing type database system which is provided. 3. Databases are respectively arranged in main storage areas of a plurality of computers connected via a network, data stored in a specific computer is used as original data, and a computer having the original data is used as a base host. In another computer different from the specific computer, the same replica data as the original data stored in the base host is stored, and the computer storing the replica data is used as a replica host, On the main storage area of the host, a replication processing unit for ensuring the sameness of the original data of the base host and the replica data of the replica host, and a transaction unit for executing transactions for performing various processes on the database. Action processing unit,
A transaction management unit that manages transactions executed by the transaction processing unit; the transaction management unit prepares transaction functions necessary for executing each transaction; , A transaction function corresponding to an issued transaction is selected, and a process for the database is executed using the transaction function. 4. A database is arranged on each of main storage areas of a plurality of computers connected via a network, data stored in a specific computer is used as original data, and a computer having the original data is used as a base host. In another computer different from a specific computer, the same replica data as the original data stored in the base host is stored, and the computer storing the replica data is used as a replica host, On the main storage area of the host, a replication processing unit for ensuring the sameness of the original data of the base host and the replica data of the replica host, and a transaction for executing transactions for performing various processes on the database. A transaction processing unit and a transaction management unit that manages a transaction executed by the transaction processing unit. The transaction management unit selects a reception unit for the issued transaction and a transaction function corresponding to the received transaction. And a transaction function loading unit for loading the selected transaction function and performing a process on the database. 5. The database comprises a lexicon as a data processing unit and a lexicon set having one or more lexicons, wherein the transaction management unit performs one or more transactions for processing the lexicon. The transaction processing database according to any one of claims 1 to 4, wherein is registered in the lexicon set as a transaction library. 6. The lexicon in the lexicon set in the transaction management unit, wherein the transaction includes a reference transaction that does not involve a change in data to be processed and an update transaction that makes a change in the data. 6. The transaction processing type database according to claim 5, wherein it is set in advance which one of the updating transactions accesses. 7. The transaction management unit stores the transaction function as a DLL file,
The DLL file is associated with the transaction library, and at the time of executing a transaction registered in the transaction library, the DLL file associated with the library is called to execute the transaction function stored therein. The transaction processing type database according to claim 5. 8. The transaction management unit registers a real name and an alias with respect to a lexicon set to be accessed by a transaction, and registers a transaction with either the real name or an alias of the lexicon set when executing the transaction. 6. The lexicon set that is accessible.
Transaction processing database described in. 9. A database stored in any one of the plurality of hosts stores original data of system management data created by the transaction management unit. A management application program and a system management transaction executed by the system management application program are arranged. The system management transaction includes each transaction executed by the transaction processing unit and data to be processed by each transaction. 6. The transaction processing type database system according to claim 5, wherein