JP2001184282A - Oltp system and storage medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To execute acceptance processing by accepting a request even from an unspecific client. SOLUTION: In this OLTP system, a server side is provided with an unspecific client ID registering table 44 for registering plural non-use clients ID, and at the time of accepting a connection request from an unspecific client 3, a client corresponding process 43 searches one non-use client ID in a non-use state at present, and sets client information corresponding to the non-use client ID, and defines the non-use client ID as a use decided client ID, and transmits it to the unspecific client 3 being the origin of request. Afterwards, the use decided client ID is used as a key with a server 4 so that the transmission and reception of data can be realized.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an OLTP system and a recording medium for executing a request process from a client, and more particularly to an OLTP system and a recording medium for performing a connection process and a failure recovery process for a request from an unspecified client. .

[0002]

2. Description of the Related Art Conventionally, in an OLTP system for transmitting and receiving message data between a client and a server, in order to cope with a system failure, the server itself stores a processing history in a file on a secondary recording medium such as a magnetic disk. It is common to save. Such a file is called a journal file. Note that the history data includes an input message from the client, an output message to the client, a database update record, and the like.

In the above system, when a system failure occurs, history data is read from a journal file, and a series of recovery processes such as updating a database and returning a message to a client are performed. When returning a message, the server needs to uniquely identify the client.
Generally, an (identifier) is allocated, and when there is a connection request from the client side, the client ID of the client is generally registered.

[0004] Hereinafter, the processing between the specific client 1 and the server 2 in the conventional system will be described with reference to FIG.

(A) The specific client 1 is the server 2
Sends a connection request based on the client information such as the IP address.

(B) The client process 21 on the server 2 side accepts the connection request and sets information such as the IP address of the client 1 as a client ID corresponding to the registered client ID in the registered client ID table 22. At the same time as registration, a client message receiving process 23 is generated.

(C) The client message receiving process 23 receives a message from the client 1. This message includes the client ID and the input message. The reception process 23 sends the client ID, the input message and (c) to the input message journal file 24 to leave a history.
(F) is uniquely identified, a transaction ID for distinguishing from a specific client's business process is stored, and an input message including the client ID and the transaction ID is sent to the application 25. Execute.

(D) The application 25 refers to an RDB (relational database) 26 based on a client ID, an input message, and the like, performs an update process of corresponding data and the like, and updates the data including the client ID and the transaction ID. The RDB image is passed to the journal management process 27.

(E) The journal management process 27
After the application process ends, the R
The DB image or the like is stored in the RDB journal file 28, and a reply output message or the like is sent to the client message sending process 29 which is the next step.

(F) The client message transmission process 29 stores a client ID, an output message, a transaction ID, and the like in the output message journal 30 to leave a history, and returns the output message and the like to the client 1.

By the way, when a failure occurs in either the client 1 or the server 2 during the above-described series of processing, the following recovery processing is performed.

* When a failure occurs in the client 1 and the client 1 recovers.

When the client 1 outputs a connection request again with the client ID as an argument, the server 2 accepts the connection request. At this time, it is considered that the business process has already been completed. Therefore, the server 2 returns an output message or the like to the client 1 while viewing the output message journal file 30.

* When a failure occurs in the server and the server is recovered.

For all the client IDs that were being processed, the input message journal file 24, the RDB journal file 28, and the output message journal file 30 are referenced to determine how far the processing has progressed. continue.

[0016]

However, in the system described above, the client 1
D is assigned and the server 2 manages the client ID, so the following problems have been pointed out.

One is that every time a client 1 is added, it is necessary to additionally set a client ID in the server 2.

The other is that OLTP cannot be applied to a system that is accessed by an unspecified client such as the Internet. If the application is to be applied, it is necessary to perform a troublesome process of separately issuing a request for a registration procedure from the client and registering the client in the server 2.

The present invention has been made in view of the above circumstances, and it is an object of the present invention to provide an OLTP system in which a server uniquely identifies an unspecified client without having to register a client ID and executes a required process.

It is another object of the present invention to provide an OLTP system that appropriately executes a recovery process when a system failure is recovered.

Still another object of the present invention is to provide a recording medium in which a recovery processing program for appropriately performing a recovery processing upon recovery from a system failure is recorded.

[0022]

(1) To solve the above problems, an OLTP system according to the present invention provides an OLTP system for transmitting and receiving data between a client and a server.
In the (online transaction) system, the server comprises: an unspecified client ID registration unit for registering a plurality of unused client IDs; and when the server receives a connection request based on client information from the unspecified client, Selecting an unused client ID that is currently in an unused state from among a plurality of unused client IDs registered in the ID registration unit, setting the unspecified client ID that is the client information to a use state, and Client corresponding process means for sending the unused client to the unspecified client as a use confirmed client ID.

According to the present invention having the above-described configuration, even if there is a connection request from an unspecified client, the unused client ID is searched for an unused client ID, and the unspecified client information is obtained. By setting the ID, the unused client ID is transmitted to the unspecified client as the use confirmed client ID. Therefore, the server can uniquely identify the client without registering the client ID in advance, and thereafter, the unspecified client can be identified. The server can transmit and receive data based on the use-determined client ID.

(2) A new component is added to the component (1).
A client ID transmitted from the unspecified client based on a client message receiving process generated by the client corresponding process means
And an input message journal registering means for registering an input message; a database journal registering means for updating a database based on the input message, registering the updated database image and outputting an output message; Output message journal registering means for registering, and further, the client handling process means receives a connection request from the unspecified client having a failure under a use-determined client ID including a recovery request after recovery from the failure. Means for determining whether the use-determined client ID exists in the unspecified client ID registration means, and means for determining the content of a recovery request when the use-determined client ID exists, This decision From the output message journal registering means to send the output message to the unspecified client in the case of continuation designation, and processing data executed by each journal registration means in the case of new designation from the judgment result. New processing means for deleting and executing the processing from the beginning.

According to the present invention, when an input message is transmitted from an unspecified client in response to a connection request, the input message is stored in order to save a history based on the message. A journal of data update images and output messages is created and registered, but during the processing, for example, when a failure occurs in an unspecified client, and after that, the unspecified client returns to the server based on the use confirmed client ID. A request for restoration is issued.

Here, the client ID existence confirmation means of the client corresponding process of the server, when the use-determined client ID exists in the unspecified client ID registration means, judges that it is being executed and the content of the recovery request. Then, if the determination is a continuation designation, the continuation processing means sends an output message to the unspecified client. If the designation is new, the new processing means deletes the executed processing data and starts the processing from the beginning. Even if the client is unspecified, even if it is an unspecified client, a recovery process required for the server after recovery from the failure using the use-determined client ID dynamically generated on the server side without registering the client ID in advance Can be requested.

(3) According to the present invention, a use-determined client newly transmitted from the unspecified client based on a client message receiving process generated by a client corresponding process means is newly added to the component (1). Input message journal registering means for registering an ID and an input message; database journal registering means for updating a database based on the input message, registering the updated database image, and outputting an output message; And an output message journal registering means for registering, when the client-specific process means has not been accessed for a certain period of time after the failure of the unspecified client, the client registered process means This configuration is provided with a processed data erasing unit that deletes processing data, and an unused state setting unit that sets a corresponding unused client ID of the unspecified client ID registration unit from a used state to an unused state.

According to the present invention, with the above configuration, when there is no access for a certain period of time after the occurrence of a failure of an unspecified client, the corresponding unused client ID of the unspecified client ID registration means is changed from the used state to unused. Since the state is set, it is possible to receive a connection request from an unspecified client while effectively utilizing a plurality of unused client IDs.

(4) The present invention has a non-specific client ID registration unit for registering a plurality of unused client IDs, and has a computer-readable recording recording a program for executing a process relating to a message of the non-specific client. Medium, the server-side program retrieves an unused client ID that is currently in an unused state from the unspecified client ID registration unit when receiving an unspecified client ID that is client information from the unspecified client. An unused client ID search function, a use state setting function of writing the unspecified client ID and setting the used state in correspondence with an unused client ID in an unused state by the search by this function; Using the searched unused client ID A computer ID that reads a program recorded on a recording medium and sends a client ID in response to an unspecified client connection request. It is possible to give.

(5) Further, according to the present invention, when the server-side computer reads the program on the recording medium,
An unused client ID search function that searches for an unused unused client ID from an unspecified client ID registration unit that registers a plurality of unused client IDs when receiving an unspecified client ID that is client information from an unspecified client. When there is an unused client ID in an unused state as a result of the search by this function, a use state setting function for writing an unspecified client ID to make the used state correspond to the unused client ID, A use-determined client ID sending function for returning to the requesting unspecified client as a use-determined client ID; and a reconnection request including a recovery request based on the use-determined client ID after recovery from the faulty unspecified client. When the client is confirmed A client ID existence confirmation function for determining whether or not D exists in the unspecified client ID registration unit; and a recovery request content determination function for determining the content of the recovery request when a use-confirmed client ID exists by this function. When the continuation designation is made from this determination result, a continuation processing function of returning the output message to the unspecified client, and when the decision result is a new designation, delete the processing data executed by checking the journal file, By realizing the new processing function of executing the processing from the beginning, it is possible to realize appropriate recovery processing according to the content of the recovery request after recovery from the failure of the unspecified client.

[0031]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 shows an OLT according to the present invention.
FIG. 1 is a configuration diagram illustrating an embodiment of a P system. In addition,
4, the same parts as those in FIG. 4 are denoted by the same reference numerals, and the detailed description thereof will be omitted. This system is composed of a large number of unspecified clients 3,... And a server 4 that executes required business processes including connection requests from each unspecified client 3 and a specified client (not shown).

The unspecified client 3 stores the client ID in a main storage device or an external storage device.
A D storage area 31 is formed. This ID storage area 3
No. 1 does not store any ID in the initial stage, but when a use-determined client ID dynamically assigned from the server 4 is transmitted from the server 4 after sending a connection request, the use-determined client ID is stored. Save.

The server 4 includes a recording medium 41 for recording a program such as a failure recovery process, a CPU for executing necessary processes in accordance with a program recorded on the recording medium 41, in addition to a business process in response to a request from the client 3. The configured data processing unit 42 and a client ID for unspecified client registration to which an undetermined client ID automatically created at a predetermined timing or created in advance is set
In addition to a table (hereinafter, referred to as an unspecified client ID registration table) 44, a registered client ID table 22 in which client IDs are assigned to specific clients, which are components similar to FIG. 4, and an input message journal file 24 , RDB 26, RDB journal file 28, and output message journal file 30.

As the recording medium 41, a CD-ROM is generally used, but other than that, for example, a magnetic disk, a magnetic tape, a CD-ROM, a DVD-RO
M, a floppy disk, an MO, a CD-R, a memory card, or the like may be used.

The unspecified client ID registration table 44 includes an unused client ID generated from a random ID generation source (not shown) when receiving information on the unspecified client at the time of receiving the connection request from the data processing unit 42. Or an unused client ID for registering an unused client ID set in advance by the server user
In the setting column, an unspecified client ID such as an IP address, which is information relating to the reception of the unspecified client 3, is set in association with an unused client ID which is unused when the connection request of the unspecified client 3 is received. A client ID setting column is provided. Note that a flag setting column for setting a flag indicating a use state may be provided together with the unspecified client ID setting column or instead of the unspecified client ID setting column.

When receiving a connection request from the unspecified client 33, the data processing unit 42 selects an unused client ID that is currently unused from among the unused client IDs in the unspecified client ID registration table 44. After setting information on the unspecified client 3 in association with the selected unused client ID,
An unused client ID is returned as a use confirmed client ID, and a client message receiving process 23 that executes the same processing as in FIG. 4, a message update to the RDB 26, etc. Application 25, a journal management process 27, a client message transmission process 29, and the like.

Next, the operation of the OLTP system as described above will be described with reference to FIG. (1) First, client information such as an IP address from the unspecified client 3 (also a client ID)
When a connection request is transmitted based on the connection request, the client process 43 reads the program recorded on the recording medium 41 after receiving the connection request, and executes the following processing.

That is, the client corresponding process 43
Reads the client ID of the received argument (S
1), this client ID is a registered client I
It is determined whether or not the client is registered in the D table 22 (S2). If the client is registered, it is determined that the client is a predetermined specific client. The process is executed (S3). This series of processing is as described in (c) to (f) described in the related art, and will not be described here.

If the client ID is not registered in the registered client ID table 22, it is determined whether the client ID contains information such as a failure recovery request (S1 to S4: Failure recovery request presence / absence). Judgment function).

On the other hand, when the request is not a failure recovery request or the like, an unused client ID that is currently in an unused state is searched from the unspecified client ID registration table 44 (S5: unused client ID search function). I related to the client corresponding to the used client ID
The information (client ID) such as the P address is written and set to the use state (S6: use state setting function), and the searched unused client ID is used as the use-confirmed client ID. It is returned (S7: use confirmed client ID sending function).

The unspecified client 3 stores the use confirmed client ID returned from the client process 43 in the ID storage area 31. Thereafter, the message transmission and reception between the client 3 and the server 4 is performed using the use confirmed client ID as a key. The processes related to the client message 23, the application 25, the journal management process 27, and the client message transmission process 29 have been described in the related art (c) to (c).
As described in (f).

(2) By the way, unspecified client 3
Indicates that the ID storage area 3
Since a restoration request including a continuation designation or a new designation is transmitted based on the use-confirmed client ID stored in No. 1, in this case, the process goes to Step 4 through Steps S 1 to S 3
Move to In this step 4, since the client ID includes data such as continuation designation, new designation, and the like, the process proceeds to step S8 to determine whether or not the unspecified client ID registration table 44 contains the use confirmation client ID of the received argument. (Client ID existence confirmation function).

Here, if it does not exist, an error message or the like is output. If it does exist, it is determined whether or not there is a flag for continuation designation in the accepted client ID of the argument used, and there is a flag for continuation designation. In the case of (1), after viewing the output message journal file 30, an instruction is issued to the client message transmission process 29, and the client message transmission process 29 returns the client ID and the output message to the unspecified client 3 (S
9, S10: continuation processing function).

If there is a request for a new designation in step S9, the input message journal file 24,
The RDB journal file 28 and the output message journal file 30 are checked, data and the like that are being processed are deleted, and the processing is executed from the beginning (S11, S12: new processing function).

(3) A failure occurs in the client 3,
When recovery is not performed as it is or when reconnection request is not output after client recovery. In this case, the server 4
A timeout value is set in advance, and a process as shown in FIG. 3 is executed with a timing when there is no access after receiving a failure occurrence status signal or a connection request from the unspecified client 3. That is, the client process 43 of the server 4 checks whether the client 3 has timed out (S21). If the time during which no access has been made exceeds the time-out value (S21, S22: time-out check means), the unspecified client Using the unused client ID in the used state set in the ID registration table 44 as a key, the input message journal file 24, the RDB journal file 28, the output message journal file 30, etc. are searched to determine how far the processing has been performed. The processing being performed is deleted, and the original state is restored (S23: processed data erasing means). Further, the unspecified client ID set in the unspecified client ID registration table 44 is deleted, and the unused client ID is set in an unused state (S24: table unused state setting unit).

Executing the timeout process in this way makes it possible to reuse unused client IDs without using them all.

(4) When a failure occurs in the server 4,
Thereafter, when the server 4 recovers from the failure, as described in the related art, all the client IDs being processed are processed.
, Input message journal file 24, RD
By referring to the B journal file 28 and the output message journal file 30, the extent to which the process has progressed is specified, and the process is executed so as to take over the process.

Therefore, according to the above-described embodiment, the information on the client of the unspecified client that has made the connection request is associated with the unused client ID in the unused state from among the plurality of unused client IDs. Unspecified client ID registration table 44 for setting
Is provided, it is possible for even a large number of unspecified clients to receive a message on the server side and execute required processing.

After receiving the unspecified client, the server 4 sets the ID of the unused client in the unused state.
Is used as the determined client ID and is transmitted to the requesting unspecified client 3.
Data can be transmitted / received between the server and the server 4 using the use-determined client ID.

Further, when a failure has occurred in the unspecified client 3 and the unspecified client recovers thereafter, the unspecified client 3 requests the server 4 for recovery. At this time, the server 3 responds to the use confirmed client ID and the contents of the recovery request. For example, since the continuation process or the new process is executed, even the unspecified client 3 can appropriately realize the recovery process.

In addition, the present invention can be variously modified and implemented without departing from the gist thereof.

[0052]

As described above, according to the present invention, an unspecified client can be uniquely identified and required processing can be executed without the need to register an unspecified client ID. An OLTP system capable of performing processing can be provided.

Further, the present invention provides an unspecified client ID
It is possible to uniquely identify an unspecified client and execute a required process without having to register a file, and to provide a recording medium on which a program for appropriately performing a recovery process upon recovery from a system failure is recorded.

[Brief description of the drawings]

FIG. 1 is a configuration diagram showing an embodiment of an OLTP system according to the present invention.

FIG. 2 is a flowchart for explaining the operation of the system shown in FIG. 1;

FIG. 3 is a flowchart for explaining the flow of server-side processing when there is no access after a failure recovery of an unspecified client.

FIG. 4 is a configuration diagram of a conventional OLTP system.

[Explanation of symbols]

 3 Unspecified client 4 Server 23 Client message reception process 24 Input message journal file 25 Application 26 RDB 27 Journal management process 28 RDB journal file 29 Client message transmission process 30 Output message journal file 41 Recording medium 42 Data processing unit 43 Client process

Claims (5)

[Claims] 1. An OLTP (Online Transaction) system for transmitting and receiving data between a client and a server, the server comprising: an unspecified client ID registration unit for registering a plurality of unused client IDs; When a connection request is received based on the client information, an unused client ID in an unused state is selected from a plurality of unused client IDs registered in the unspecified client ID registration means, and the client information is selected. A client corresponding process means for setting an unspecified client ID to be used and sending the unused client to the unspecified client as a use-determined client ID;
An OLTP system characterized in that data transmission and reception are enabled using D as a key. 2. The OLTP system according to claim 1, wherein a use-determined client ID / input message transmitted from said unspecified client based on a client message receiving process generated by said client corresponding process means. Message journal registering means for registering an update image and an output message to be updated based on a message; further, the client handling process means includes: When a connection request is received based on the client ID, a client ID existence confirming means for judging whether or not the use-determined client ID exists in the unspecified client ID registering means; Means for judging the content of the restoration request, continuation processing means for sending the output message to the unspecified client in the case of continuation designation from the judgment result, and the continuation processing means in the case of new designation from the judgment result. An OLTP system comprising: a new processing unit for deleting the processing data executed by the journal registration unit and executing the processing from the beginning. 3. The OLTP system according to claim 1, wherein a use-determined client ID and an input message transmitted from the unspecified client based on a client message receiving process generated by the client corresponding process means. Message journal registering means for registering an update image and an output message to be updated based on a message; further, the client corresponding process means, when there is no access for a certain period of time after the failure of the unspecified client, A processed data erasing unit that deletes the executed process data registered in the registration unit; and an unused state setting unit that sets the corresponding unused client ID of the unspecified client ID registration unit from the used state to the unused state. Establishment OLTP system, characterized in that. 4. A computer-readable recording medium having an unspecified client ID registration unit for registering a plurality of unused client IDs, and recording a program for executing a process related to an unspecified client message, wherein the server The side program, when receiving an unspecified client ID that is client information from the unspecified client, an unused client ID search function for searching an unused client ID that is currently in an unused state from the unspecified client ID registration unit; When there is an unused client ID in an unused state as a result of a search by this function, a use state setting function for writing the unspecified client ID and setting the used state to a use state in correspondence with the unused client ID; Use ID as client ID Recording medium; and a use deterministic client ID sending function for sending back to the original unspecified clients. 5. An unspecified client ID registration unit for registering a plurality of unused client IDs, an input message of the unspecified client, a database update image accompanying the input message, and a journal file such as an output message to the unspecified client. A computer-readable recording medium storing a program for executing a process related to a message of an unspecified client, wherein the server-side program receives an unspecified client ID as client information from the unspecified client. An unused client ID search function for searching for an unused client ID that is currently in an unused state from the unspecified client ID registration unit; A use state setting function for writing the unspecified client ID and setting the use state to a use state, and a use confirmed client ID for returning the retrieved unused client ID to the use-unspecified client as the use-confirmed client ID The sending function, and when a reconnection request including a recovery request is received from the unspecified client in which the fault has occurred after recovery from the fault, based on the use-determined client ID, the use-determined client ID exists in the unspecified client ID registration unit. A client ID existence confirming function for determining whether or not to perform, a recovery request content determining function for determining the content of the recovery request when the use confirmed client ID exists by this function, and a case where the continuation is designated from the determination result. Continuation processing function for returning the output message to the unspecified client A new processing function for checking the journal file, deleting the executed processing data, and executing the processing from the beginning when a new designation is made based on the determination result.