JPH0895874A - Remote procedure call processing method - Google Patents

Abstract

PURPOSE: To make remote procedure calls(RPC) from plural processes belonging to the same transaction, to the same server with the same server process. CONSTITUTION: Respective servers have schedule queues 6-8 of RPCs to plural service processes, an extension chain table 10 which manages a connection state, and an extension chain queue 9 which accepts RPC requests from processes belonging to the same transaction. On the client side, queuing in the schedule queues 6-8 in the case where the transaction, to which its process belongs, is not connected to an opposite server or in the extension chain queue 9 in the case where a connection is waited, is performed, and when the connection is already made, direct transmission through a socket is performed. On the server side, requests are taken out of the schedule queues 6-8 firstly and then a request is taken out of the extension chain queue 9, and then, a request sent through the socket is taken out lastly to execute the RPCs from plural processes belonging to the same transaction with the same server process.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a remote procedure processing method for making a remote procedure call in a computer system.

[0002]

2. Description of the Related Art With the progress of parallel computer technology, a parallel processing method for executing one process by a plurality of computers has become important. Remote procedure call (remote procedure call, hereinafter called RPC) has been proposed as one of parallel processing methods.

Regarding RPC, translated by Yoichi Shinoda: "UNIX Network Programming", Toppan, 1993, pp809-842.
(Original work; W. Richard: "UNIX NETWORK PROGRAMING", Prin
ce Hall, 1990.).

RPC is a procedure call extending between two processes, and is a procedure call of another process from its own process. The calling process is called the client (or client process), and the called other process is called the server (or server process). The server process may be on the same system as the client process (called the local host) or on another system (called the remote host).

The RPC processing procedure from the client to the server is as follows. First, a local function called a client stub is called from the client function. The client stub collects a procedure name, arguments, etc. to be executed by the server as one message. This message is called an RPC message. Next, the client stub issues an OS system call to send the RPC message to the server stub of the server process. In the server stub of the server process,
It decodes the received RPC message, acquires the function to be executed, the arguments, etc., and executes the specified function. The return value of the function is passed to the server stub, where it is put together as one message. This message is called a response message.
The server stub issues an OS system call to the client stub and sends a response message. The client stub decodes the received response message and returns the return value of the function to the client that called the RPC.

In the above procedure, the client
The means to connect to the server process that should execute RPC is important. In order to connect the client and server, a means to find the remote host where the other server exists,
A means for specifying the server process to be connected in the remote host is required.

As means for finding the remote host where the partner server exists, means for using a centralized database, means for broadcasting server information to other hosts at the time of server registration, etc. are used. To identify the server process to connect to in the remote host, prepare a server daemon for distributing service requests in the host where the server exists, and send the RPC message from the client to the server daemon once. After that, a method such as allocating to the server process in the RPC receivable state is used.

There are various methods for realizing RPC,
In the present invention, each server has a plurality of server processes that provide the same service function, and the RP for each server
Handles the client / server model that sends C messages to the server via the schedule queue. In this model, the RPC message sent from the client to the server is queued in the schedule queue prepared for each server, and the queued requests are sequentially fetched and executed by the server process.

In the above client / server model
RPC execution modes include synchronous non-chained RPC,
There are synchronous chained RPCs, asynchronous non-chained RPCs, and asynchronous chained RPCs.

The difference between synchronous / asynchronous will be described. The synchronous type is
The client is blocked until the RPC response message is received from the server. Asynchronous type continues client processing without waiting for reception of RPC response message. Asynchronous RP
The C response message is received by issuing the asynchronous RPC response reception processing function.

The difference between chain and non-chain is whether or not the connection between the client and the server is disconnected. Chained RPC continues the connection with the server and sends the next RPC message directly to the server process without queuing in the schedule queue. Therefore, the same server process can execute multiple RPCs. On the other hand, the non-chained RPC disconnects the connection with the server at the end of execution. Non-chained RPC
Is executed, the next RPC message is queued in the schedule queue, so RPC may not always be executed by the same server process as the last time.

A known example of a chained RPC that enables the connection relationship between a client and a server to be continued is Xerox C.
There is ourir system (trade name) (see the above-mentioned publicly known document). The Courir system calls the open function to establish the connection between the client and server before issuing the RPC, and then executes the RPC multiple times. The connection between the client and server is not broken during each RPC execution. The disconnection of the connection between the client and the server is executed by issuing the close function. By doing so, it becomes possible to execute multiple RPCs from one process in the same server process.

[0013]

In the chained RPC, it is possible to cause a single server process to execute a plurality of RPCs issued from one process. However, when a series of processes is executed by a plurality of processes (for example, parallel processing by a parallel computer), RPC to the same server generated from the plurality of processes cannot be executed by the same server process.

As an example in which RPCs are issued from a plurality of processes to the same server process in a series of processes,
There is database transaction processing. In transaction processing in which multiple databases are accessed simultaneously, the client process issues RPCs to multiple database servers and executes the processing. From one database server to RP which is common to each database server
Issue C to execute the process. Therefore, when executing one transaction process, RPCs are issued to one server via multiple server processes.

FIG. 2 is a diagram for explaining the flow of the above processing in the conventional method. In the figure, rectangles 1 to 5 each having a small square on the upper left shoulder indicate a process, and a rectangle 6
8 is a schedule queue FIFO (First-In First
-Out) Indicates a cue. The symbol T01 described in the process indicates a global transaction identifier (hereinafter, referred to as GTID) indicating a series of processes.

First, the RPC message sent from the parent process (1) to the server A is queued in the server A schedule queue 6 (21) and taken out by the child process a (2) belonging to the server A process group 40. (22). Then, the parent process (1) and the child process a
A connection relationship is established between (2) and the process is executed. RPC for server C issued during execution of child process a
The electronic message is queued in the schedule queue 8 of the server C (23) and taken out by the grandchild process c1 (4) belonging to the server C process group 42 (24). Then, the connection relationship is established between the grandchild process c1 (4) and the child process a (2), and the processing is executed.

On the other hand, the RPC issued from the parent process (1) to the server B is also processed in the same manner, taken out by the child process b (3) via the server B schedule queue 7 and executed (25, 26). ).

Here, it is assumed that RPC is issued from the child process b to the server C. At this time, there is no process of the server C having a connection relationship with the child process b. Therefore, the RPC message from the child process b to the server C is queued in the server C schedule queue 8 (2
7). In the server C process group, the grandchild process c1 is connected to the server A, so the request queued by the child process b is another process, the grandchild process c2.
It is taken out (28) by (5).

As shown above, the series of processes whose GTID is T01 are executed by process 1 to process 5, and the RP from different processes (2 and 3) to server C is executed.
It can be seen that C runs in separate processes (4 and 5). Therefore, when the series of processing contents is the transaction processing as described above, the transaction start processing and the transaction end processing must be performed in the respective grandchild processes (4 and 5) of the server C. Is one of the factors that deteriorate the efficiency of database processing. There is also a problem that the number of processes (process resources) occupied by one transaction increases.

An object of the present invention is to provide a remote procedure call processing method for executing RPC for the same server issued by a plurality of processes executing one transaction process in the same server process.

Another object of the present invention is to provide an RPC for the same server issued by a plurality of processes even when the RPC is an asynchronous RPC that continues processing without waiting for reception of a response message from the RPC. It is to provide a remote procedure call processing method that is executed in the same server process.

[0022]

The present invention is a remote procedure call for calling a procedure of a server existing on its own host or on another host from a client process, wherein the server is a plurality of servers providing the same service. In the remote procedure call processing method, there are a plurality of client processes that are transaction-managed, and the remote procedure call is composed of processes and is issued by the client process is processed by any one of the plurality of server processes. ,
If each client process has a global transaction identifier that identifies the transaction being managed, first issue a remote procedure call to the server from any one of multiple client processes managed by the same transaction. And a step of assigning the remote procedure call to one server process to connect the server process and the client process, and connecting the server process to the global of the connected client process. A second step of storing a transaction identifier and connection information related to the connection in an extended chain table, and from any one of a plurality of client processes under the transaction control. When issuing a remote procedure call to the server next time, the client process refers to the extended chain table to obtain connection information of the server process connected to another client process under the same transaction management, And a third step of issuing a remote procedure call to the server process, thereby sharing one server process among a plurality of client processes of the same transaction.

A schedule queue for receiving an execution request of the first remote procedure call from the client process is provided for each server, and the issuance of the remote procedure call in the first step is performed by sending a message of the remote procedure call to the schedule. This can be done by queuing in a queue.

Further, for each server, the extended chain table and the extended chain queue that store the execution relation of each transaction and the remote procedure call with the server are provided, and the extended chain table includes the global transaction identifier and the global transaction identifier. It is a table that stores a transaction of a global transaction identifier and an extended chain state indicating a connection state with the server, handle information of a server process being connected, and information about an extended chain queue. In the second step, The global transaction identifier and the handle information of the connected server process are stored in the extended chain table, and in the third step, the remote procedure call of the remote procedure call is stored in the extended chain queue of the server. By queuing the statement,
It is advisable to issue a remote procedure call to a server process that is already connected to another client process under the same transaction control.

That is, specifically, in the present invention, an extended chain RP which extends the function of the conventional chain RPC.
C Provide processing method. In the extended chain RPC, it is possible to allocate RPCs issued by multiple processes to one server process by newly providing an extended chain table and an extended chain queue for each server. The extended chain table stores GTID which is a transaction identifier and connection information of a server process which is in a connection state with the transaction.
When an RPC is issued to a server from a client process under transaction management, the extended chain table is searched by the GTID of the client, and the following processing is performed according to the result.

If the GTID is not yet registered in the extended chain table, it means that another process having the same GTID has not yet issued a connection request to the server. Therefore, the RPC message is sent to the server. While queuing in the schedule queue, the GTID of the client is registered in the extension chain table, and the extension chain status of the server is set to wait for connection. Then, when the RPC message is retrieved by the server process, the extended chain status of the server is set to connected for the GTID entry of the extended chain table, and the handle information of the server process (the message to the server process Connection information for sending directly).

When the GTID is already registered in the extended chain table and the extended chain state is already connected, another process having the same GTID has already completed connection processing to the server. Therefore, the handle information of the server process stored in the table is acquired, and the RPC message is directly transmitted to the server process.

If the GTID is already registered in the extended chain table and the extended chain state is waiting for connection, connection of a connection request to the server already issued from another process having the same GTID. Since the processing is incomplete, the RPC message cannot be sent directly to the server process. Therefore,
An extended chain queue dedicated to the GTID is created, and an RPC message is queued in the extended chain queue. The RPC messages queued in the extended chain queue are fetched and executed by the server process after the RPC messages queued in the schedule queue are fetched by the server process and executed. By doing this, a preceding RPC from another process with the same GTID
And subsequent RPCs can be executed by a single server process. When the extended chain queue is empty,
The queue is deleted, and the server process shifts to the reception of a directly transmitted message.

Since the extended chain table provided for each server is referenced / updated by both the client process and the server process, it is arranged in the shared memory. If the shared memory between remote hosts is not installed in the computer system that executes this extended chain RPC, the same processing is performed via the scheduler daemon. That is, the scheduler daemon is started up in advance on each host where the server exists, and the RPC message for the remote host is first sent directly to the scheduler daemon on the remote host, and the scheduler daemon refers to the extended chain table of the other server. Then, it decides whether to queue the received RPC message in the schedule queue, send it directly to the remote server process, or queue it in the extended chain queue.

As described above, in the present invention,
It is characterized by having a mechanism that assigns RPCs issued by multiple processes in the same transaction to the same server to the same process using the global transaction identifier as a key.

[0031]

As described above, according to the present invention, the same GT is used by using the extended chain table and the extended chain queue.
It is possible to allocate RPCs issued by multiple processes with IDs to one server process. Therefore, it becomes possible to combine RPC connection / disconnection processing for the same server at one time.

Further, in the chain RPC, the server process is secured in the client process from the start of connection between the client and the server until the disconnection. Since the number of server processes that can be created in a host is generally limited, the number of concurrent chain RPCs for the same server is limited by the number of processes.

On the other hand, in the extended chain RPC according to the present invention, one server process processes RPCs issued by a plurality of processes having the same GTID, and therefore, it is also effective in reducing server process resources. Have.

[0034]

Embodiments of the present invention will be described below. In this embodiment, a remote procedure call (hereinafter called RPC)
The extended chain RPC, which is a new feature of, will be explained in detail with reference to the figure.

FIG. 1 shows the extension chain in this embodiment.
It is a figure which shows operation | movement of RPC. In the figure, rectangles 1 to 5 with small squares on the upper left shoulder indicate processes,
Boxes 6 to 9 represent FIFO queues. The FIFO queue can be realized by various methods using resources that can be shared between processes, such as using a message queue provided by the system and creating a FIFO queue in a shared memory area.

The solid line with an arrow in this figure shows the flow of the RPC message between processes, and the broken line with an arrow is
The reference operation of the table stored in the shared memory is shown. Broken-line squares 40 to 42 indicate a server process group configured by a plurality of processes providing the same service function. In this embodiment, there are three types of servers, server A, server B, and server C, and a server process group is configured for each server. Schedule queues 6 to 8 for accepting a request to the server are prepared in one server process group.

It is now assumed that the parent process (1) is under transaction management and the global transaction ID (hereinafter referred to as GTID) is T01. Parent process (1) chained RP to server A and server B
It is assumed that the C message is issued, and the server A and the server B each issue a chained RPC message to the server C. Further, it is assumed that the connection between the respective servers has not been established yet. The flow of processing will be described below with reference to FIG.

First, the chained RPC message for the server A issued by the parent process (1) is queued in the server A schedule queue 6 (11). The queued RPC message is taken out by the child process a (2) of the server A process group 40 and executed (12).

When issuing a chained RPC message from the child process a to the server C, first, the extended chain table 10 of the server C is searched with GTID = T01 (3
0). Then, since it is found that the information satisfying the above condition is not registered, the chain RPC message is queued in the schedule queue 8 of the server C (1
3). At this time, the extended chain table 10 of the server C
Then, register that the RPC with GTID T01 is in the connection waiting (REQ_WAIT) state. The queued RPC message is fetched by the grandchild process c1 (4) of the server C process group 42 and executed (14). At this time, it is registered in the extended chain table 10 of the server C that the RPC having the GTID T01 is in the connected (ONLINE) state with the grandchild process c1, and at the same time, the handle information of the grandchild process c1 is also registered in the extended chain table 10. Register (32).

Next, the chained RPC message for the server B issued from the parent process 1 is queued in the schedule queue 7 of the server B (16). The queued RPC message is fetched by the child process b (3) of the server B process group 41 and executed (17).

When issuing a chained RPC message from the child process b to the server C, first, the extended chain table 10 of the server C is searched with GTID = T01 (3
1). Then, it is found that the request to the server C whose GTID is T01 has already been made by another process, its extended chain state is the ONLINE state, and the partner server process is the grandchild process c1. Therefore, using the handle information of the grandchild process c1 stored in the extended chain table 10, the RPC message is directly transmitted to the server c (18).

As described above, the extended chain table showing the correspondence between the global transaction ID and the server process being connected is prepared for each server.
Chained RPCs issued by multiple processes with the same GTID can now be executed by the same server process.

Although omitted in the above description in order to avoid complication, in reality, the server A and the server B are omitted.
Also has an extended chain table. When issuing an RPC to the server A and the server B from the parent process, the extended chain state is acquired by referring to the extended chain table of the server A and the server B, and the RPC message is queued in the server's schedule queue. , Or send directly to the connecting server process.

In the above description, it is assumed that the child process b issues the RPC message to the server C after the RPC message issued by the child process a to the server C is fetched by the grandchild process c1. Therefore, in the following, the child process a
When the RPC message issued by the server to the server C exists in the schedule queue of the server C and the child process b issues the RPC message to the server C,
The operations of the server B and the server C will be described.

First, when the chained RPC message is issued from the child process b of the server B to the server C, the extended chain table 10 of the server C is searched with GTID = T01 (31). Then, it is found that a request to the server C having GTID T01 is being made by another process and the state is the connection waiting (REQ_WAIT) state.

In the REQ_WAIT state, the RPC message cannot be directly sent to the server process because the partner server process is undetermined. Also, the RP
When the C message is queued in the schedule queue 8 of the server C, the RPC message is fetched by another process of the server C, so that the RPC messages issued by the child process a and the child process b to the server C are not necessarily the same server. It is not always executed.

Therefore, in such a state, the GPID
The extension chain queue 9 of the server C whose T01 is T01 is temporarily created, and the RPC message is queued in the T01 extension chain queue 9 (19). The RPC message queued in the T01 extended chain queue 9 of the server C is fetched by the grandchild process c1 from the RPC message queued in the schedule queue 8 of the server C (14).
After being executed, it is taken out by the grandchild process c1 and executed (20).

When the server process c1 receives the chained RPC message from the schedule queue 8, after that,
The electronic messages are sequentially taken out from the extended chain queue 9. When the extended chain queue 9 becomes empty, the extended chain queue 9 is deleted and the RPC message reception from the socket is awaited.

FIG. 12 shows an embodiment of the extended chain table. A schedule management table (50) for managing the schedule queue of each server and an extension chain table (51, 5) for managing the extension chain queue of each server are provided on each node where the server exists.
2, 10) exist. Schedule management table (5
There is only one 0) in the relevant node, but there are as many extended chain tables (51, 52, 10) as there are servers in the relevant node.

The schedule management table (50) includes a server name (61), a schedule queue identifier (62),
The number of messages in the schedule queue (63), the pointer (64) to the extended chain table, and the like are held. The extended chain table (51, 52, 10) has the GTID (6
5), the extended chain status (66), the server process handle information (67), the extended chain queue ID (68), the number of electronic messages in the extended chain queue (69), and the like are held.

When searching the entry of "GTID = T01" of the server C, first, the schedule management table (50)
Is searched for by "server name = server C", the extended chain table pointer (64) of the entry is traced to obtain the server C extended chain table (10), and then the server C extended chain table (10) is searched for "GTID. = T01 "to retrieve the information of the entry.

FIG. 3 is a diagram showing the transition of the extended chain state between the client and the server in the extended chain RPC. Waiting for connection (REQ_WAIT) as extended chain status
There are four types: a state 80, a chain connection wait (CHAIN_WAIT) state 81, a chain message transmission state (CHAIN_SEND) 83, and a connected state (ONLINE) state 84.

The REQ_WAIT state is a state in which the first RPC message is queued in the schedule queue and the RPC for the server is not yet performed from another process having the same GTID. In this state, there is no extended chain queue.

The CHAIN_WAIT state is a state in which the first RPC message is queued in the schedule queue,
In addition, it indicates that another process with the same GTID has issued an RPC for the server and the RPC message is queued in the extended chain queue. In this state, RPC newly issued to the server
Messages are sequentially queued in the extended chain queue.

The CHAIN_SEND state shows a state in which the first RPC message has been fetched by the server process, but there are still RPC messages queued in the extended chain queue. In this state, the server process sequentially fetches RPC messages from the extended chain queue. On the other hand, the RPC message newly issued to the server is
Refer to the handle information of the server process and send directly to the connected server process via the socket.

The ONLINE state is a state after all the messages queued in the extended chain queue have been taken out, and the server process sequentially takes out the RPC messages directly sent via the socket.

Next, the transition condition of the extended chain state will be described. First, when queuing the first RPC message in the schedule queue, information about the GTID is registered in the extended chain table. At this time, the extended chain state is initialized to REQ_WAIT (84).

When the RPC request is taken out from the schedule queue by the server process in the REQ_WAIT state, the extended chain state shifts to the ONLINE state (9
0). When another process with the same GTID issues an RPC to the server in the REQ_WAIT state, the extended chain state changes to the CHAIN_WAIT state (85) and a new extended chain queue is created to queue the RPC message. To ing.

In the CHAIN_WAIT state, when another process having the same GTID issues an RPC request to the server, the RPC message is queued in the extended chain queue and the CHAIN_WAIT state is maintained. Yes (86). In the CHAIN_WAIT state, if the first RPC message queued in the schedule queue is fetched by the server process, the extended chain state will be CHAIN_SE.
Transition to the ND state (87).

In the CHAIN_SEND state, the server process sequentially fetches RPC messages from the extended chain queue.
If another RPC message remains in the extended chain queue when the RPC message is retrieved, the CHAIN_SEND state is maintained (88). When an RPC message is retrieved and no other RPC message remains in the extended chain queue,
Clears the extended chain queue and turns on the extended chain state
Transition to the LINE state (89).

In the ONLINE state, the server process sequentially takes out the RPC message sent directly to the server process via the socket. At this time, the extracted RPC message is a chained RPC that continues the expansion chain.
If so, the extended chain state is kept ONLINE (91). If the fetched RPC message is an RPC that terminates the extension chain, the entry of the GTID is deleted from the extension chain table of the server, and the extension chain state disappears (92). Then, the server process itself transits to a state where the next RPC message is fetched from the schedule queue.

Next, a more detailed processing flow for realizing the extended chain RPC will be described with reference to the flow charts 4 to 11.

The types of RPC described in this embodiment are as follows.
There are a total of four types of combinations of chained RPC / non-chained RPC and synchronous RPC / asynchronous RPC.

The chained RPC maintains a connection between the client and the server to allocate the next RPC to the same server process. In addition, the chain RPC when the client is under transaction management is processed as an extended chain RPC. The non-chained RPC is used as a termination RPC in addition to the one-time RPC. That is, if a non-chained RPC is executed while the client and server are in the chain state, the RPC
After the execution of, ends the connection between the client and the server.

In the case of synchronous RPC, the process is suspended until the client receives the response message from the server process, whereas in the case of asynchronous RPC, the client receives the response message from the server process. Continues processing without waiting for the reception of the response message from the server process
It is received by the client process by explicitly issuing the response message reception function. In the following description, the flow of processing for executing these four types of RPC will be described.

FIG. 4 is a diagram showing the flow of RPC transmission processing on the client side. In the RPC transmission process on the client side, first, the handle information of the client process is acquired (101), and the chain table is searched to acquire the RPC connection information of the client and the server (10).
2).

The chain table is a table unique to the client process that holds the RPC connection state between the client process and the server. FIG. 13 shows an example of the chain table.

In this embodiment, the server name (70), server process handle information (71), and RPC connection status (7
The chain table (53) is composed of four fields of 2) and the response reception state (73). As shown in the figure, the handle information (71) is composed of the network address of the node, the network type, and the port number of the socket. By using the handle information (71), it is possible to directly send / receive data to / from the server process existing in the remote host. By referring to this chain table, it is possible to acquire the connection relation with an arbitrary server, the handle information of the server process being connected, the presence / absence of reception of a response from the server, and the like.

Next, the RPC connection state between the client and the server is determined (103), and if IN_CHAIN, handle information of the partner server is acquired from the chain table (107). When the handle information is already registered (108), the handle information is used to directly transmit the RPC message to the connected server (109), and when the handle information is not registered (108), the later-described RPC transmission start processing is executed (110).

On the other hand, if the RPC connection state between the client and the server is not registered in the chain table (10
3) Execute the RPC transmission start processing described later (104), and if the type of RPC to be executed has chain specification (105), set the RPC connection status of the client and server to IN_CHAIN and set it in the chain table. Register (10
6).

Upon completion of the above processing, the response message is received from the server process. First, if the type of RPC to be executed is not synchronous RPC (11
1) Since the reception of the response message is executed by the response message reception function, the RPC identifier necessary for identifying the response message is returned to the client and the process is terminated (119).

On the other hand, in the case of synchronous RPC (111),
First, wait for the reception of a response message from the server process (1
12). Then, after receiving the response message, if the type of RPC to be executed is the chain designation (113), it is confirmed whether the handle information of the server process has been registered in the chain table (114). In this case, the handle information of the server process is acquired from the response message and registered in the chain table (115).

When the type of RPC to be executed is not chain specified (113), the RPC connection state is confirmed (11
6) In case of IN_CHAIN, RP of client and server
The C connection information is deleted from the chain table to cancel the chain state (117). Finally, in the case of synchronous RPC, the response message is returned to the client and the processing is terminated (118).

FIG. 5 is an RP called from the client side RPC transmission process (steps 104 and 110) of FIG.
It is a figure which shows the flow of C transmission start processing.

In the RPC transmission start processing (200), first,
The server information of the transmission destination is acquired (201). As a method of acquiring server information, various existing methods such as a method of inquiring to a server that centrally manages information about all servers in the system and a method of inquiring of several distributed servers can be applied. .

Next, it is judged whether or not the server of the communication partner exists in the own node (local host) (20
2) If it does not exist in the local node, the RPC message is directly transmitted to the scheduler daemon of the node in which the partner server exists (206), and the RPC transmission start processing is terminated. If the server of the communication partner exists in the local node (20
2) Determine whether the client process is under transaction control and whether the type of RPC to be executed is a chained RPC or an unchained RPC (203,
204).

If the client is not under transaction control or if the type of RPC to be executed is a non-chained RPC, the RPC is an extended chained RPC.
Therefore, the RPC message is queued in the schedule queue (211), and the RPC transmission start process ends. In the case of transaction control and chained RPC, it is an extended chained RPC, so first search the extended chain table of the partner server by GTID (205),
From (a) below depending on the extended chain status with the other server
Perform the processing of (d).

(A) If the entry of the GTID is not registered in the extended chain table, since it is the first RPC for the server, the entry of the GTID is registered in the extended chain table of the partner server (209). , Set the extended chain status to REQ_WAIT (210), and finally queue the RPC message in the schedule queue (211), and RPC
The transmission start process ends.

(B) When the extended chain state is REQ_WAIT, the RPC from another process that already has the same GTID
Since the request is queued in the schedule queue, the extended chain state is set to CHAIN_WAIT (212),
An extended chain queue is created (213), and an RPC message is queued in the created extended chain queue (21).
4), the process ends.

(C) If the extended chain state is CHAIN_WAIT, the RP from another process that already has the same GTID
Queue the RPC request in the extension chain queue because the C request is queued in the schedule queue and the RPC request from another process having the same GTID is already queued in the extension chain queue. (214), and the process ends.

(D) If the extended chain status is other than the above, since the RPC request from another process having the same GTID has already been connected to the server process, the handle of the other server is obtained from the extended chain table of the other server. The information is acquired (215), the RPC message is directly transmitted to the partner server using the handle information (216), and the process is ended.

FIG. 6 is a diagram showing the flow of RPC reception processing on the server side. The RPC reception process (300) on the server side is
Controlled by RPC reception status. There are three types of RPC reception states: a schedule queue waiting state (RECV_QUE), an extended chain queue waiting state (RECV_EX), and a socket reception waiting state (RECV_SOCK). RPC reception status is
Initialized to RECV_QUE state after server startup (30
1). After that, it branches according to the RPC reception status (30
2) The following processes (a) to (c) are executed.

(A) When the RPC reception state is RECV_QUE,
The schedule queue reception process described later is performed (30
3) The client handle information is registered in the server side RPC control information (304). Then, when the type of the received RPC has chain designation (305), the RPC reception state of the server is set to RECV_EX (306).

(B) When the RPC reception state is RECV_EX,
An extended chain queue reception process described below is performed (307).
At that time, if the retrieved RPC message is empty (3
08), set the RPC reception status of the server to RECV_SOCK (3
09), the following process (c) is continuously performed. R received
When the PC message is not empty, the type of the received RPC is judged (312), and when the chain is not specified, the chain end processing described later is executed (313) and the RPC reception state is set to RECV_QUE (314).

(C) When the RPC reception state is RECV_SOCK, first, the client handle information is acquired from the RPC control information held by the server (310), and the RPC message from the client is waited via the socket (311). next,
The type of the received RPC is determined (312), and if the chain is not specified, the chain end processing described later is executed (313), and the RPC reception state is set to RECV_QUE (31).
4).

After performing any of the processes (a) to (c) above, the request type of the received RPC message is confirmed, and if the request type is a server end request (315), the server is ended. . In other cases, since it is a service execution request, the specified service function is executed (316), and the execution result is sent to the client as a response message (31).
7). After that, the RPC reception status is determined again (302),
The above processing is executed according to the RPC reception state.

FIG. 7 is a diagram showing the flow of the schedule queue reception process (303 in FIG. 6). In the schedule queue reception process (400), first, the RPC message is extracted from the schedule queue of the server (401) and the type of the received message is confirmed. Then, it is judged whether or not the client that issued the RPC is under transaction management (402), and if it is not under transaction management, the received RPC message is returned and the processing is terminated (412).

If the client that issued the RPC is under transaction management (402), the server is also under transaction management (403). Next, the type of the received RPC is judged (404), and if the chain is not designated, the received RPC message is returned and the processing is terminated (412). If the chain is specified (4
04), the RPC is determined to be an extended chain RPC, and the following processing is performed.

That is, first, the extension chain table of the self server is searched by GTID (405) to acquire the extension chain state. If the extended chain status is REQ_WAIT (406), the handle information of the server process (that is, its own process) is registered in the extended chain table (40).
7), set the extended chain state to ONLINE (408), R
The PC message is returned and the processing ends (412). If the extended chain status is CHAIN_WAIT (40
6) The handle information of the server process (that is, its own process) is registered in the extended chain table (409), the extended chain state is set to CHAIN_SEND (410), the RPC message is returned, and the process is terminated (412). If the extended chain state is other than that (406), it is considered that an abnormality has occurred in the state transition, and an error is returned (411).

FIG. 8 is a diagram showing the flow of the extended chain queue reception process (307 in FIG. 6). In the extended chain queue reception process (500), first, the extended chain table of the local server is searched by GTID (501) to obtain the extended chain state.

If the extended chain status is other than CHAIN_SEND (502), since there is no extended chain queue, an empty telegram is returned (509). When the extended chain status is CHAIN_SEND (502), the RPC message is taken out from the extended chain queue corresponding to the GTID (503). When all RPC messages have been extracted from the extended chain queue (504), the extended chain queue corresponding to the GTID is deleted (506), and the extended chain state is set to ONLINE (507). Finally, the RP I took out
The C message is returned to the server side RPC reception processing routine, and the processing ends (508).

FIG. 9 shows the chain end processing (31 in FIG. 6).
It is a figure which shows the flow of 3). Chain end processing (60
In 0), first, it is confirmed whether or not the own server process is under transaction management (601), and if it is not under transaction management, the client handle information of the RPC reception control information is deleted (607), and processing is performed. Is finished (608).

If it is under transaction control (601), in order to disconnect the extended chain state, first, the extended chain table of the local server is searched by the GTID of the local server process (602), and the extended chain state is set. get. If the GTID of the local server process is not registered in the extended chain table (603), transaction settlement processing is performed (606), client handle information is deleted (607), and processing ends (608). .

When the extension chain state is CHAIN_SEND (603), first, the extension chain queue is deleted (604), the entry of the GTID is deleted from the extension chain table (605), and the transaction settlement processing is performed. (606), the handle information of the client is deleted (607), and the process ends (608).

When the extended chain status is other than CHAIN_SEND (603), the entry of the GTID concerned is deleted from the extended chain table (605), transaction settlement processing is performed (606), and the client handle information is deleted. (607), the process ends (608).

FIG. 10 is a diagram showing a flow of an asynchronous RPC response reception process. In asynchronous RPC, the client can receive the response message from the server by explicitly executing this process.

In this processing (700), first, the reception of a response message from the server process is awaited (701). And
After the response message is received, if the RPC type corresponding to the received response message has chain designation (702), the chain table is searched and the RPC connection information of the server and client corresponding to the received response message is acquired. Shi (70
3) It is confirmed whether the handle information of the partner server is registered in the table (704), and if it is not registered, the handle information of the partner server is acquired from the response message and registered in the chain table (705). ). Then, the response message and the RPC identifier are returned to the client and the processing is terminated (706).

FIG. 11 shows that when the server is on another node (remote host), the RP is sent from the client to the partner server.
It is a figure which shows the flow of a process of the scheduler daemon which transfers C telegram.

The scheduler daemon (800) first waits for reception of an RPC message from a client of another node (801). When a message arrives at the scheduler daemon, it is first checked whether the message is a termination instruction message for the scheduler daemon (80
2) If the message is a termination instruction message, the processing of the scheduler daemon is terminated (803).

In other cases (802), since it is an RPC message for the server of the own node in which the scheduler daemon exists, first, the destination server transmitting the RPC message is specified and the destination server information is acquired ( 804).

Next, the contents of the RPC message are confirmed (805,
806), if the sending client is not under transaction control or the RPC to be executed is a non-chained RPC, the RPC message is queued in the schedule queue of the other server because the RPC does not become an extended chained RPC. Ing (811). If the client is under transaction management and the RPC to be executed is a chained RPC (805, 806), it becomes an extended chained RPC. First, the extended chain table of the other server is searched by GTID (807), The process branches from the extended chain state with the partner server (808) and the following processes (a) to (d) are performed.

(A) If the entry of the GTID is not registered in the extended chain table, since it is the first RPC for the server, the entry of the GTID is registered in the extended chain table of the partner server (809). The extended chain state is set to REQ_WAIT (810), and the RPC message is queued in the schedule queue (811).

(B) When the extended chain status is REQ_WAIT, RPC from another process that already has the same GTID
Since the request is queued in the schedule queue, the extended chain state is set to CHAIN_SEND (812),
An extended chain queue is created (813), and an RPC message is queued in the created extended chain queue (81).
4).

(C) When the extended chain state is CHAIN_WAIT, the RP from another process that already has the same GTID
Queue the RPC request in the extension chain queue because the C request is queued in the schedule queue and the RPC request from another process having the same GTID is already queued in the extension chain queue (814).

(D) If the extended chain status is other than the above, since the RPC request from another process having the same GTID has already been connected to the server process, the handle of the other server is obtained from the extended chain table of the other server. The information is acquired (815), and the RPC message is directly transmitted to the partner server using the handle information (816).

After performing the processes from (a) to (d) above, the scheduler daemon returns to the state of waiting for the RPC message reception from the client of another node (801).

[0107]

According to the present invention, a remote procedure call to the same server from a plurality of client processes having the same global transaction identifier can be performed.
It is possible to execute in one service process. The same applies to an asynchronous remote procedure call that continues processing without waiting for the reception of a response message. Therefore, the number of server processes occupied by one transaction is one for each server, which is effective in saving process resources. Further, since the handle information of the server process is stored in the extended chain table, the connection process between the client and the server process can be speeded up.

[Brief description of drawings]

FIG. 1 is a diagram illustrating a processing flow of an extended chain RPC according to the present invention,

FIG. 2 is a diagram for explaining the flow of processing by a conventional chain RPC;

FIG. 3 is a state transition diagram of an extended chain state,

FIG. 4 is a flowchart showing RPC transmission processing on the client side;

FIG. 5 is a flow chart showing RPC transmission start processing on the client side;

FIG. 6 is a flowchart showing RPC reception processing on the server side,

FIG. 7 is a flowchart showing a schedule queue reception process on the server side;

FIG. 8 is a flowchart showing an extended chain queue reception process on the server side,

FIG. 9 is a flowchart showing chain end processing on the server side;

FIG. 10 is a flowchart showing an asynchronous RPC response reception process in the asynchronous RPC,

FIG. 11 is a flowchart showing the processing of the scheduler daemon,

FIG. 12 is a diagram showing an example of a management table for realizing an extended chain RPC;

FIG. 13 is a diagram showing an example of a chain table that manages a chain state of a client process.

[Explanation of symbols]

1 ... Parent process, 2 ... Child process a, 3 ... Child process b,
4 ... Grandchild process c1, 5 ... Grandchild process c2, 6 ... Server A schedule queue, 7 ... Server B schedule queue,
8 ... server C schedule queue, 9 ... server C for T01
Extended chain queue, 10 ... Server C extended chain table, 50 ... Schedule management table, 53 ... Chain table.

Claims (6)

[Claims] 1. A remote procedure call for invoking a procedure of a server existing on its own host or on another host from a client process, wherein the server is composed of a plurality of server processes providing the same service. The remote procedure call issued from is processed by any one of the plurality of server processes. In the remote procedure call processing method, there are a plurality of transaction-managed client processes, and each client process is managed. If there is a global transaction identifier that identifies the existing transaction, a remote procedure call is first made to the server from any one of a plurality of client processes managed by the same transaction. A first step of issuing; in the server that has received the remote procedure call, assigning the remote procedure call to one server process to connect the server process and the client process, and A second step of storing a global transaction identifier and connection information related to the connection in an extended chain table; and a remote procedure call from any one of the plurality of client processes under the transaction control to the server. When issuing a message, the client process refers to the extended chain table to obtain connection information of a server process connected to another client process under the same transaction management, and sends the connection information to the server process. And a third step of issuing a remote procedure call, thereby, the remote procedure call processing method characterized by sharing one server process across multiple client processes the same transaction. 2. A schedule queue for receiving an execution request of the first remote procedure call from the client process is provided for each server, and the remote procedure call is issued by a message of the remote procedure call in the first step. The remote procedure call processing method according to claim 1, wherein the remote procedure call processing is performed by queuing in the schedule queue. 3. An extended chain table for storing each transaction and a remote procedure call execution relationship between the server and the server is provided for each server, and the extended chain table stores the global transaction identifier and the global transaction identifier. A table that stores an extended chain state indicating a connection state between a transaction and the server, handle information of a server process being connected, and information about an extended chain queue, and in the second step, in the extended chain table, The global transaction identifier and the handle information of the connected server process are stored, and in the third step, the message of the remote procedure call is queued in the extended chain queue of the server. , Remote procedure call processing method according to claim 2 which issues a remote procedure call to the server process with another client process managed the same transaction already connected. 4. In the first step, (a) the client process manages a transaction by executing a remote procedure call from the client process to the server in its own host when the connection relation is not established between the client process and the partner server. If it is under transaction control, and if it is under transaction management, a process of searching the extended chain table of the remote server that executes the remote procedure call with the global transaction identifier, and (b) the global transaction identifier is the extended If the global transaction identifier is not registered in the chain table, the global transaction identifier is registered in the extended chain table, the connection state between the transaction and the server is set to the connection waiting state, and the remote procedure call execution request is issued to the partner server. (C) if the global transaction identifier is already registered in the extended chain table and the connection state between the transaction and the server is in the connection waiting state, the transaction and the server (D) a process of putting a connection state into a chain connection waiting state, temporarily creating an extended chain queue for the transaction, and queuing a remote procedure call execution request in the extended chain queue; If the transaction has been registered in the chain table and the connection state between the transaction and the server is in the chain connection wait state, the remote procedure call execution request is queued in the extended chain queue already created for the transaction. Processing, and (e) if the global transaction identifier is already registered in the extended chain table and the connection state between the transaction and the server is in the connected state, the server process handle information registered in the extended chain table 4. The remote procedure call processing method according to claim 3, wherein the remote procedure call execution request is directly transmitted to the server process being connected via the socket. 5. Further, on each host where the server exists,
A scheduler daemon for transferring remote procedure call execution requests from the client process of another host to the server of the local host is provided, and when the connection relationship between the client process and the other server is not established, the client process Remote procedure call to the other server, the process of transferring the remote procedure call execution request to the scheduler daemon of the other host where the other server exists, and the scheduler daemon on the other server sends the received remote procedure call to the other server. A remote procedure call processing method of transmitting by the processing of (a) to (e) according to claim 4. 6. The server process has a server reception state that manages where to receive a remote procedure call execution request. If the server reception state is waiting for a schedule queue, the server process waits for the schedule queue of the server. When a remote procedure call execution request is fetched and the execution request source client is under transaction management,
The extended chain table is searched by the global transaction identifier to acquire the connection relationship between the transaction and the server, and when the connection relationship is waiting for connection, the connection relationship is set to the connected state and the server reception state is set. When the socket reception wait state is set, and when the connection relationship is a chain connection wait state, the connection relationship is set to the chain message transmission state and the server reception state is set to the extended chain queue wait state, and the server reception state is extended. If you are waiting for a chain,
The execution request of the remote procedure call is extracted from the extension chain queue of the server corresponding to the transaction in the chain, and if the extracted execution request is the last execution request queued in the extension chain queue, the extension chain The process of setting the connection relationship between the relevant transaction in the table and the server to the connected state and setting the server reception state to the socket reception waiting state, and when the reception state of the server is socket reception waiting, from the connected client. By executing the process to retrieve the remote procedure call execution request sent directly via the socket, one server process can execute the remote procedure call execution requests sent from multiple client processes with the same global transaction identifier. Remote procedure call processing method according to claim 3.