JP2003203000A - Method for executing transaction - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To enable a stateful object to execute a transaction on the same application process without session management. <P>SOLUTION: Respective application processes 310, 320 and 330 set their own process ID in a stateful object as an object ID when the respective application processes 310, 320 and 330 produce the stateful object. When a request transmission and reception mechanism 200 receives a transaction execution request, the request transmission and reception mechanism 200 judges whether or not an object related to the transaction execution request is a stateful object on the basis of the state information of the object, and transmits the transaction execution request to the application process 310, 320 or 330 which has the same information as that of the object ID of the stateful object as a process ID when the object is judged 'to be a stateful object'. <P>COPYRIGHT: (C)2003,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention, in a client-server system operating in multi-process, makes it possible to execute a transaction by always operating a stateful object created by an application process on a server on the application process. The present invention relates to a transaction execution method (stateful object transaction execution method in a client server system).

Here, matters related to the term "stateful" will be added.

"Stateful" means holding a state or an execution result. On the other hand, not holding the state or execution result is called "stateless".

The "stateful process" in the client-server system means a process in which the process is completed by calling a plurality of transactions from the client. On the contrary, a process in which the process is completed by calling the transaction once is called "stateless process".

"Stateful" is a concept, and an object that realizes it is "stateful object".
(A "stateful object" is an object that realizes the above "stateful").

That is, a "stateful object" created by an application process and operating on the application process operates as shown in a and b below.

A. Even if the database is updated in the execution of a certain transaction, commit / rollback to the database is performed in the transaction to be executed thereafter.

B. Update the values of object member variables and global variables that depend on each other between transactions.

The stateful object operating on the application process has the following characteristics a and b.

A. Stateful objects cannot be reused because of the dependency of variables in the objects. Therefore, the application process always creates an object when a creation request is made by a client and deletes (releases) the object when a deletion (release) request is made. One object is always prepared for one client.

B. A plurality of transactions requested to be executed by a certain client have mutual dependency among the transactions. Therefore, the stateful object (stateful object corresponding to the client) must execute the transaction on the same application process or thread. Therefore, even if there are other application processes or threads waiting for execution, it is not possible to operate the stateful object on them and execute the transaction.

[0012]

2. Description of the Related Art FIG. 7 is a block diagram for explaining the structure and operation of a conventional transaction execution system of this type.

This transaction execution system is configured to include a server 1100, a client 1510 that issues a request to the server 1100, a client 1520, and a client 1530.

On the server 1100, the request transmission / reception mechanism 1
200 and the application process 1 that executes the request
310, an application process 1320, an application process 1330, and a mapping table 1600.

The client 1510 has a session 171.
0 (session: 1) is used to connect to the server 1100, client 1520 is connected to the server 1100 using session 1720 (session: 2), and client 1530 is connected to the session 1730 (session:
3) is used to connect to the server 1100.

The request transmission / reception mechanism 1200 manages and references the mapping table 1600.
It is configured to include 10.

The application process 1310 includes a process ID (IDentification). In this application process 1310, an object 1410-1 is created (generated) in response to an object creation request from the client 1510. The object 1410-1 is configured to include state information. Object 1410-1 created here
But the client 1510 has an object 1410-2
And will be used for subsequent requests. The above is
The same applies to the application process 1320 and the application process 1330.

The mapping table 1600 is composed of a session management table 1610 and a process ID management table 1620 (which also has correspondence information of both tables).

A session management mechanism such as the session management table 1610 is disclosed in, for example, Japanese Patent Laid-Open No. 2001-2001.
"Session management information (shared memory)" in the invention (distributed session management system for web applications) described in Japanese Patent No. 14242, and Japanese Patent Laid-Open No. 2000-1633.
"Session information table T" in the invention described in Japanese Patent Publication No. 46 (session identification method and session management method, and an information providing system for realizing the method and a recording medium recording the program), and Japanese Patent Laid-Open No. 10-3.
It is found in the "session management table" in the invention (WWW client server system) described in Japanese Patent No. 26243.

The conventional transaction execution system having such a configuration operates as follows due to a transaction execution request.

That is, the client 1510 uses the object 1410-2 passed from the request transmission / reception mechanism 1200 in the server 1100 to request transmission / reception mechanism 12.
Issue a transaction execution request to 00.

The request transmission / reception mechanism 1200, when the transaction execution request is issued using a stateful object, the table management mechanism 121.
0 refers to the mapping table 1600, and the session 171 of the client 1510 that made the request
It is checked which application process 0 corresponds to, and the request is distributed to the corresponding application process (here, the application process 1310). If it is a new session, the session management table 1610 is updated and the object 1
Application process 131 that created 410-1
The process ID of 0 and the identification information of the session are mapped.

The application process 1310 to which the request is distributed executes the transaction related to the request.

The application process 1310 sends the execution result of the transaction to the request transmission / reception mechanism 120.
Pass (return) to 0.

The request transmission / reception mechanism 1200 returns the execution result of the transaction to the requesting client 1510.

[0026]

The above-described conventional transaction execution method has the following problems.

The first problem is the session and the process I.
This means that a mapping table and its management are required to correspond to D.

The reason why such a problem exists is that there is the following causal relationship.

That is, the stateful object is
Transactions must always be executed on the same application process due to dependencies between transactions and variables in objects. Therefore, in order to always distribute a transaction execution request (request via a session) using a stateful object from a certain client to the same application process, mapping between the two (the relevant session for specifying the relevant client and the relevant session It is necessary to keep a mapping with the application process). In the case of a single process system (system that operates in a single process), since there is only one application process, it is sufficient to cause an object to execute a transaction only on that application process. However, in a multi-process system (system that operates with multiple processes), even though there are multiple application processes, the request from the client (transaction execution request) has no information for identifying the application process at all. As described above, a means for mapping the client and the corresponding application process is needed.

The second problem is that the above conventional technique (transaction execution method as shown in FIG. 7) is considered on the assumption that the client always makes a request in the same session. If it is disconnected, the request from the client cannot be passed to the corresponding application process (application process mapped to the client).

The reason why such a problem exists is that even if the session is managed by the mapping table,
When the client connects again after the session has been disconnected, the session has changed, so the mapping table does not work at all, and the request sending / receiving mechanism distributes the request to the same application process as that of the previous client. This is because it will not be possible.

The third problem is that the session management becomes useless when the sessions from the clients are bundled by the Web server or the like.

The reason why such a problem exists is that the session management table in the mapping table does not work from the bundled sessions, and the mapping between the bundled sessions and the process IDs in the multi-process configuration. Then, it is impossible to determine which client the request came in in this session (which application process should be distributed).

In view of the above points, an object of the present invention is that "a stateful object on a client-server system operating in multi-process can be used without session management.
The purpose of this is to provide a transaction execution method that makes it possible to execute a transaction on the same application process.

[0035]

According to the transaction execution method of the present invention, in a client-server system that operates in multiple processes and can execute a transaction by a stateful object, an object creation request, a transaction execution request, and an object are issued to a server. When creating an object based on a client that issues a release request and an object creation request, state information for identifying whether the created object is a stateful object or a stateless object is set in the object, and , Each application process in the server that sets its own process ID as an object ID when the stateful object is created, When a request from a client is received and the result of processing based on the request is sent back to the client and a transaction execution request is received, the object is a stateful object based on the state information of the object related to the transaction execution request. If it is determined whether there is a stateful object, the process ID is the same information as the object ID of the stateful object.
And a request transmission / reception mechanism in the server that sends the transaction execution request to the application process.

Here, the request transmission / reception mechanism in the above-mentioned transaction execution system performs control for receiving a request from a client, determining the type and content of the request, and allocating the request to an appropriate application process based on the determination. When the transaction execution request issued using the stateful object is distributed, the object ID of the stateful object
A request receiving means for allocating the transaction execution request to an application process having a process ID, and a control for returning the result of the processing for the request distributed by the request receiving means to the client of the request issuing source. And a result returning means for returning the stateful object including the state information indicating “stateful” as the result of the object creation request of “stateful object” and the object ID having the “process ID of the application process that created the stateful object”. It is possible to configure.

In the above transaction execution method, the association between the stateful object and the application process that created the stateful object is set to "the process ID of the application process that created the stateful object" in the stateful object. Alternatively, it can be realized by setting "information indicating which application process created the stateful object" other than "process ID of the application process that created the stateful object" in the stateful object. Is.

Further, according to the present invention, the first step in which the server receives the request from the client, and the second step in which it is determined whether the request received in the first step is an object creation request or not. And a third step of allocating the request to one of the executable application processes when the request is determined to be an object creation request in the second step, and the request in the third step. A fourth step of the distributed application process creating an object, and a step of setting the process ID of the application process as an object ID of the stateful object when the object created in the fourth step is a stateful object. 5 steps and created object The sixth step of returning (replying) the request to the requesting client, and the object related to the request based on the state information when “the request is not an object creation request” is determined in the second step. (Object used to issue the request)
Is a stateful object, and a seventh step is an application process having the object ID of the object as a process ID when it is determined in the seventh step that the object is a stateful object. An appropriate application process (one of the application processes waiting to be executed) when it is determined that the relevant object is not a stateful object in the eighth step of distributing the request to the
And a ninth step of allocating the request to the first step, and a tenth step of determining whether the request allocated by any one of the eighth step and the ninth step is an object release request or a transaction execution request. Then, when it is determined that the request is an object release request in the tenth step, the application process to which the request is distributed in one of the eighth step and the ninth step assigns the object to the object. An eleventh step of releasing and returning (replying) the release result to the requesting client; and the eighth step when the request is judged to be a transaction execution request in the tenth step; The application process to which the request was distributed in any of the ninth steps. There can also be implemented as a transaction execution method comprising the twelfth step of returning (return) was a result of the execution perform a transaction to the requesting client according to the request.

Furthermore, the present invention is a client-server system that operates in multi-process and can execute transactions by stateful objects.
Assuming that there is a client that issues an object creation request, transaction execution request, and object release request to the server, "When creating an object based on the object creation request, the created object is a stateful object. There is an application process that sets state information for identifying whether the object is a stateless object, and when a stateful object is created, sets its own process ID as an object ID in the stateful object. Server that receives the request from the client and returns the result of the processing based on the request to the client, and when the transaction execution request is received, the transaction The object based on the state information of the object according to the execution request is equal to or stateful object, the object ID the process ID of the same information and the stateful object when it is determined to be "stateful objects"
It is also possible to realize it as a program for functioning as a request transmission / reception mechanism that sends the transaction execution request to the application process that has.

[0040]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Next, the present invention will be described in detail with reference to the drawings.

(1) First Embodiment

FIG. 1 is a block diagram showing the configuration of a transaction execution system according to the first embodiment of the present invention.

Referring to FIG. 1, the transaction execution method according to the present embodiment has a server 100 and a server 1.
00, a client 510, a client 520, and a client 530 that make a request to the client 00. As the server 100, for example, a web server can be assumed.

The request transmission / reception mechanism 20 is provided on the server 100.
0 and the application process 31 that executes the request
0, an application process 320, and an application process 330.

The application process 310 includes a process ID. Application process 31
0 is a client (here, client 51
An object is created (generated) in response to an object creation request from 0). An object is state information that is information indicating whether the object is a stateful object or a stateless object, and an object I that is identification information of the object.
And D. The object created here is passed to the client 510 and used in the next and subsequent requests (transaction execution request and object release request from the client 510 to the server 100). The above is the application process 32
The same applies to 0 and the application process 330.

Although three clients and three application processes are shown in FIG. 1 here, it goes without saying that the number of clients and application processes is not limited to three in implementing the present invention. Absent.

The request transmission / reception mechanism 200 includes the request receiving means 2
01 and result reply means 202.

2 and 3 are flow charts showing the processing of the transaction execution method according to the present embodiment. This processing is performed by a request transmitting / receiving mechanism request receiving step S1, an object creation request determining step S2, a request allocating step S3, an object creating step S4, a stateful object determining step S5, an object ID setting step S6, and an object sending step. S7, result return step S8, state information determination step S9, object ID / process ID verification step S10, "stateful" corresponding request distribution step S11, "stateless" corresponding request distribution step S12, and request content determination step S13, an object release step S14, a release result sending step S15, a transaction execution step S16,
It comprises a transaction execution result sending step S17.

FIG. 4 is a block diagram for explaining a specific operation when creating an object of the transaction execution method according to this embodiment. Here, the object 410-1, the object 420-1, and the object 430-1 are objects created by the application process 310, the application process 320, and the application process 330, respectively. Also, the object 410-1
And the object 410-2 are the same, and are represented by using different symbols depending on whether they are present on the server 100 side or the client 510 side (object 420-1 and object 420-2. Relationship and objects 430-1 and 430-
The same applies to the relationship with 2.)

FIG. 5 is a block diagram for explaining a concrete operation at the time of transaction execution / object release in the transaction execution method according to this embodiment.

Next, the overall operation of the transaction execution method according to the present embodiment configured as described above will be described in detail with reference to FIGS.

Here, the client 51 is mainly used.
0 and the application process 310,
The following description will be given.

First, referring mainly to FIG. 2 and FIG.
A process flow of the transaction execution method according to this embodiment will be described.

From a client (herein, referred to as client 510) to the server 100 (request transmission / reception mechanism 2)
00) (step S1 in FIG. 2),
The request receiving unit 201 in the request transmitting / receiving mechanism 200 receives the request and determines whether the request is an object creation request (step S2).

Request transmission / reception mechanism 200 (request reception means 20)
In 1), if it is determined in step S2 that the request is an object creation request, any application process may perform the object creation. Therefore, the executable application process 310, the application process 320, and The request is distributed to an appropriate application process (here, the application process 310) of the application processes 330 (step S3).

The application process 310 to which the request is distributed creates an object (denoted as "object 410-1" according to the notation in FIG. 4) in response to the request (object creation request) (step S4).

Further, the application process 310
Based on the stateful / stateless information (information indicating whether the object to be created is a stateful object or a stateless object) included in the object creation request, the created object 410-1 is a stateful object. It is determined whether or not (step S5).

When the application process 310 determines in step S5 that "the object 410-1 is a stateful object", the application process 310 can identify which application process created the object 410-1. Its own process ID (process I of the application process 310).
The value (information) of D) is given (set) as the object ID in the object 410-1 (step S6).

When the application process 310 creates the object 410-1 as described above, the request transmission / reception mechanism 200 (result returning means 202) returns the information (created object) to the client of the creation request source. The object 410-1 is passed to (step S7).

Finally, the result returning means 202 in the request transmitting / receiving mechanism 200 returns (replies) the object 410-1 as an object 410-2 to the corresponding client (the client 510 that issued the object creation request). (Step S8).

As a result, the client 510 can receive the object 410-2 from the server 100 (request transmission / reception mechanism 200), and performs the subsequent transaction processing using the object 410-2.

On the other hand, when the request transmitting / receiving mechanism 200 (request receiving means 201) determines in step S2 that the request (request from the client 510) is not an object creation request, "the already required object is already present. Since the client 510 has made a request using the created object. ”, The object related to the request (the object used when the request is made. It is checked (determined) whether or not the state information of the "object 410-2") is "stateful" (step S9 in FIG. 3). That is, it is determined whether or not the object is a stateful object.

Request transmission / reception mechanism 200 (request reception means 20)
In 1), when it is determined in step S9 that “the relevant state information is“ stateful ””, “for the relevant object 410-2 (object 410-1), transaction execution or object is always executed on the same application process”. Must be released ”.
-2 object ID and the process ID of each application process are checked (collated) (step S1
0), the request is distributed to the corresponding application process 310 (application process having the value of the object ID as the value of the process ID) (step S11).

On the other hand, if the request transmitting / receiving mechanism 200 (request receiving means 201) determines in step S9 that the relevant state information is not "stateful", it indicates "the relevant object 410-2 (object 410-1)".
With respect to the above, it is possible to execute the transaction or release the object on any application process. ”Therefore, the executable application process 310, the application process 320,
The request is distributed to an appropriate application process (here, the application process 310) of the application processes 330 (step S12).

The application process 31 to which the request is assigned in step S11 or step S12
0 checks (determines) whether the request is an object release request or a transaction execution request (step S13).

When the application process 310 determines in step S13 that the request is an object release request (release request for the object 410-1), it releases the object 410-1 (step S14). The release result is passed to the request transmitting / receiving mechanism 200 (result returning means 202) (step S15).

On the other hand, the application process 310
When it is determined in step S13 that the request is not an object release request (transaction execution request), the transaction is executed by the object 410-1 on the application process 310 (step S16). A request sending / receiving mechanism 200 (result returning means 20)
2) (step S17).

Finally, the result returning means 202 in the request transmitting / receiving mechanism 200 returns (replies) the request result (object release result or transaction execution result) to the corresponding client 510 (request source client) (FIG. 2). Step S8).

Secondly, a concrete operation at the time of creating an object (when the request from the client is an object creation request) will be described (see FIG. 4).

In FIG. 4, the client 510 issues an object creation request to the server 100 to create an object 410-1. This object creation request includes stateful / stateless information (information indicating whether to create a stateful object or a stateless object).

In the server 100 that has received the object creation request, the request transmission / reception mechanism 200 searches for an executable application process and searches for an appropriate application process (here, the application process 310).
, And assign the object creation request to the application process 310.

The application process 310 that has received the object creation request requests the object 410-1.
To create. At this time, the application process 3
10 is a stateful / requested object creation request
It is determined whether the stateless information is “stateful” or “stateless”. If the stateless information is “stateful”, the created process object 410-1 has its own process ID (value “1”) as the object ID. To have as.

Then, the application process 31
0 is the object 410-created as described above.
1 is passed to the request transmission / reception mechanism 200.

The request transmission / reception mechanism 200 uses the object 410-1 having the process ID of the application process 310 as the object ID,
10 is returned as an object 410-2.

Third, a concrete operation at the time of executing a transaction / releasing an object (when a request from a client is a transaction execution request or an object release request) will be described (see FIG. 5).

In FIG. 5, the client 510 uses the object 410-2 passed (returned) from the request transmission / reception mechanism 200 to the server 100 (request transmission / reception mechanism 200) to execute a transaction execution request or the object 410. -1 release request (object release request) is performed.

When the object 410-2 relating to the request (the object used when the request is issued) is a stateful object, the request transmitting / receiving mechanism 200 uses the object ID of the object 410-2 as a basis. , The request is distributed to the application process 310 having the object ID (value “1”) as the process ID.

The application process 310 to which the request is distributed executes the transaction or releases the object 410-1 according to the content of the request.

Then, the application process 31
0 passes the processing result (transaction execution result or object release result) to the request transmission / reception mechanism 200.

Finally, the request transmission / reception mechanism 200 returns the processing result to the client 510.

As described above, by using the object ID of the object 410-2 related to the request from the client 510 (see the object ID), a stateful object having a dependency relationship between transactions (here, the object 410 is used). -1)
When executing a transaction, it is possible to always execute the transaction on the same application process (here, the application process 310).

(2) Second Embodiment

Next, a transaction execution method according to the second embodiment of the present invention will be described.

The transaction execution method according to the present embodiment determines the first step in which the server receives a request from the client and whether the request received in the first step is an object creation request. In the second step, the third step of allocating the request to any of the executable application processes when the request is determined to be the object creation request in the second step, and the third step Fourth, the application process to which the request is distributed creates an object
And a fifth step of setting the process ID of the application process as the object ID of the stateful object when the object created in the fourth step is a stateful object, and the created object of the request source. In the sixth step of returning (replying) to the client and the second step, "the request is not an object creation request".
If it is determined that the object related to the request (the object used to issue the request) is a stateful object based on the state information, When it is determined that the object is a stateful object, the eighth step of allocating the request to an application process having the object ID of the object as a process ID and the seventh step "the object is not a stateful object" Appropriate application process (one of the pending application processes)
A ninth step of allocating the request to a request, a tenth step of determining whether the request allocated by the eighth step or the ninth step is an object release request or a transaction execution request, and a tenth step. In step, "The request is an object release request"
If it is determined that the request is distributed in the eighth step or the ninth step, the application process releases the object and the release result is returned (replied) to the requesting client. 1
If it is determined in step 0 that the request is a transaction execution request, the eighth step or the ninth step
In the twelfth step, the application process to which the request is distributed executes the transaction related to the request and returns (responds) the execution result to the requesting client.

Here, FIG. 2 and FIG. 3 described above also correspond to flow charts showing the processing procedure of the transaction execution method according to the second embodiment of the present invention.

In this case, the above first step is as shown in FIG.
2 corresponds to step S2 in FIG. 2, the third step corresponds to step S3 in FIG. 2, and the fourth step corresponds to step S4 in FIG. The fifth step corresponds to step S5 in FIG.
And step S6, the sixth step corresponds to step S7 and step S8 in FIG. 2, the seventh step corresponds to step S9 in FIG. 3, and the eighth step corresponds to step in FIG. Corresponding to S10 and step S11, the ninth step corresponds to step S12 in FIG. 3, the tenth step corresponds to step S13 in FIG. 3, the eleventh step corresponds to step S14 in FIG. 2 corresponds to step S15 and step S8 in FIG. 2, and the twelfth step corresponds to step S16 and step S17 in FIG. 3 and step S8 in FIG.

The operation of the transaction execution method according to this embodiment is performed by referring to FIGS. 2 and 3 described in the description of the transaction execution method according to the first embodiment.
The contents are the same as the contents of the operation (processing) shown in.

(3) Third Embodiment

FIG. 6 is a block diagram showing the configuration of the third embodiment of the present invention.

Referring to FIG. 6, the third embodiment of the present invention differs from the first embodiment shown in FIG. 1 in that a request transmission / reception mechanism implementation program 600 is provided.

The request transmission / reception mechanism implementation program 600
It is read by the server 100 and controls the operation of the server 100 as a request transmission / reception mechanism 200 (a mechanism including a request receiving means 201 and a result returning means 202). The server 100 under the control of the request transmission / reception mechanism implementation program 600
The operation of (request transmission / reception mechanism 200) is exactly the same as the operation of server 100 (request transmission / reception mechanism 200 including request reception means 201 and result response means 202) in the first exemplary embodiment, and therefore detailed description thereof is omitted. To do.

[0092]

As described above, according to the present invention,
The following effects are produced.

The first effect is a mapping table for session management (mapping table 16 in FIG. 7) as seen in the conventional transaction execution method (see FIG. 7).
00) is unnecessary. As a result, there is an advantage that a management mechanism or memory for referencing / updating the session management table (session management table 1610 in FIG. 7) is not required.

The reason why such an effect occurs is that the process ID is given as the object ID of the stateful object, the information is returned to the client as the information in the object, and the client uses the object ID to request the transaction execution. This is because the server side can identify the application process to which the object is to be distributed without performing session management.

The second effect is that even if the session is disconnected, a transaction execution request can be issued to the same application process when reconnecting.

The reason why such an effect occurs is that, even if the session is terminated and the client makes a request in a new session, the application process can be identified by the object ID of the object held by the client, and the application process can be identified. This is because the process can make requests.

The third effect is that even in a situation where sessions are bundled, it becomes possible to determine which application process is requested.

The reason why such an effect occurs is, for example, W
This is because even if the sessions are bundled by the eb server, the application process can be identified by the object ID of the object held by the client, and a request can be issued to the application process.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration of an object execution method according to a first exemplary embodiment of the present invention.

FIG. 2 is a flowchart showing processing of the object execution method shown in FIG. 1, and is also a flowchart showing processing procedures of an object execution method according to a second embodiment of the present invention.

FIG. 3 is a flowchart showing processing of the object execution method shown in FIG. 1, and is also a flowchart showing processing procedures of an object execution method according to the second embodiment of the present invention.

4 is a block diagram for explaining a specific operation when creating an object in the object execution method shown in FIG.

5 is a block diagram for explaining a specific operation at the time of executing a transaction or releasing an object in the object execution method shown in FIG.

FIG. 6 is a block diagram showing a configuration of a third exemplary embodiment of the present invention.

FIG. 7 is a block diagram for explaining the configuration and operation of a conventional object execution method.

[Explanation of symbols]

100 server 200 request transmitting / receiving mechanism 201 request receiving means 202 result returning means 310, 320, 330 application processes 410-1, 420-1, 430-1 object (server side) 410-2, 420-2, 430-2 object ( Client side) 510, 520, 530 Client 600 Request transmission / reception mechanism implementation program S1 Request transmission / reception mechanism request reception step S2 Object creation request determination step S3 Request distribution step S4 Object creation step S5 Stateful object determination step S6 Object ID setting step S7 Object sending step S8 Result reply step S9 State information determination step S10 Object ID / process ID collation step S11 "Stateful" correspondence request Distribution step S12 "Stateless" correspondence request distribution step S13 Request content determination step S14 Object release step S15 Release result sending step S16 Transaction execution step S17 Transaction execution result sending step

Claims (7)

[Claims] 1. In a client-server system that operates in multi-process and may execute a transaction by a stateful object, a client that issues an object creation request, a transaction execution request, and an object release request to a server, and an object creation request When creating an object based on that, the state information for identifying whether the created object is a stateful object or a stateless object is set in the object, and if the stateful object is created, its own process Each application process in the server that sets the ID as the object ID in the stateful object, the reception of the request from the client, and the processing based on the request. When a transaction execution request is received and a transaction execution request is received, it is determined whether or not the object is a stateful object based on the state information of the object related to the transaction execution request. Process ID, the same information as the object ID of the stateful object is determined.
And a request transmission / reception mechanism in the server that sends the transaction execution request to the application process. 2. A request executed from a client is received, the type and content of the request are judged, the request is controlled to be distributed to an appropriate application process based on the judgment, and a transaction executed by using a stateful object is executed. When distributing requests, the object ID of the relevant stateful object is assigned to process I.
A request receiving unit that distributes the transaction execution request to an application process that has D, and a control that returns the result of processing for the request distributed to the application process by the request receiving unit to the client that issued the request, and is a stateful object object. A request transmission / reception mechanism including a result returning unit that returns the stateful object including state information indicating “stateful” as a result of the generation request and an object ID having “a process ID of an application process that has generated the stateful object”. The transaction execution method according to claim 1, wherein the transaction execution method comprises: 3. A correspondence between a stateful object and an application process that created the stateful object, instead of setting “process ID of the application process that created the stateful object” in the stateful object,
It is realized by setting "information indicating which application process created the stateful object" other than "process ID of the application process that created the stateful object" in the stateful object. The transaction execution method according to claim 1 or 2. 4. The transaction execution method according to claim 1, 2, or 3, wherein the server is a Web server. 5. A first step in which a server receives a request from a client, a second step in which it is determined whether the request received in the first step is an object creation request, and the first step. The third step of allocating the request to any of the executable application processes when it is determined in step 2 that the request is an object creation request, and the application to which the request is allocated in the third step. A fourth step in which the process creates an object, and when the object created in the fourth step is a stateful object, the process ID of the application process is set to the object I of the stateful object.
The fifth step of setting as D, the sixth step of returning the created object to the request source client, and the case where it is determined in the second step that the request is not an object creation request A seventh step of determining whether or not the object relating to the request is a stateful object based on the state information,
If it is determined in the seventh step that the object is a stateful object, the request is distributed to an application process having the object ID of the object as a process ID.
And a ninth step of allocating the request to an appropriate application process when the object is determined not to be a stateful object in the seventh step, the eighth step and the ninth step. A tenth step of determining whether the request distributed by any of the steps is an object release request or a transaction execution request, and in the tenth step, "the request is an object release request" is determined. In this case, the application process to which the request is distributed in any one of the eighth step and the ninth step releases the object and returns the release result to the requesting client.
And the application process to which the request is distributed in any one of the eighth step and the ninth step when it is determined that “the request is a transaction execution request” in step 10 above. And a twelfth step of executing a transaction related to the request and returning the execution result to the requesting client. 6. In a client-server system which operates in multi-process and may execute transaction by a stateful object, it is assumed that there is a client that issues an object creation request, transaction execution request, and object release request to the server. , "When creating an object based on an object creation request, set state information for identifying whether the created object is a stateful object or a stateless object, and create a stateful object. In this case, the server in which each application process that sets its own process ID as the object ID in the stateful object is present,
When a request from a client is received and the result of processing based on the request is sent back to the client, and a transaction execution request is received, the object is a stateful object based on the state information of the object related to the transaction execution request. It is determined whether or not there is, and when it is determined to be a “stateful object”, it functions as a request transmission / reception mechanism that sends the transaction execution request to an application process that has the same process ID as the object ID of the stateful object. Program for. 7. The "request transmitting / receiving mechanism" according to claim 6 is configured to include the "request receiving means" according to claim 2 and the "result returning means" according to claim 2. 6. The program described in 6.