JP2006235845A - Variable transaction processor for web system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To execute a transaction processing on an information processing system being premised on a WEB system without causing a session time-out in a variable transaction by preventing the multiple running of transaction from the same session. <P>SOLUTION: This variable transaction processor is provided with: a means for accepting transaction with variable quantity, and transferring it to an application process for processing the transaction; a means for asynchronously processing the transaction by its unique process, and notifying client terminal equipment of the processing result; and a means for notifying a console device of failure when the application process unreasonably disappears. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a transaction processing apparatus for executing a variable amount of transactions on a WEB server operating in a multi-process.

2. Description of the Related Art Conventionally, as a method for executing a transaction in a client / server system operating in a multi-process, for example, a method described in Patent Document 1 is known.
The one described in Patent Document 1 below relates to a method of executing a transaction by always operating a stateful object created by an application process on a server (including a WEB server) on the application process.
This is a method in which a stateful object can execute a transaction on the same application process without session management. The process ID is given as the object ID of the stateful object, and the information is returned in the client object. In this case, a transaction execution request is issued using the object ID, so that the server side can identify an application process without performing session management.
This eliminates the need to hold the session management table, and eliminates the need for a management mechanism such as reference or update of a disk or memory for distribution. Further, even when the session is cut off, an execution request can be issued to the same application process when the connection is made again.
JP 2003-203000 A

However, although the technique described in Patent Document 1 described above has a fixed transaction size handled by the same application and is effective in query response type transaction processing, the transaction size handled by the application process is variable and the size is small. If it is large, the session is likely to be disconnected due to the session timeout of the proxy server installed at the client site, and the application process can be easily identified when it is re-executed, but the same transaction data is multiplexed in the application process. There is a problem of running.
In other words, when the session is disconnected, the transaction is still executed on the application process. If the same transaction is requested by the client after reconnection, the requester cannot be identified, and the transaction is run in multiples. It is a problem. In addition, the transaction executed in advance is returned to the request transmission / reception mechanism after the processing is completed, but the transmission destination is lost because the session is disconnected.
On the other hand, in the case of business data update, for example, in the case of business data update, an error occurs and the error result is transmitted to the client. Accordingly, there is a problem that inconsistency occurs because the client user recognizes that the data has been successfully updated in the preceding transaction, but the client user has failed.

  An object of the present invention is to prevent multiple running of transactions from the same session and process a variable amount of transactions without causing a session timeout in transaction processing on an information processing system based on a WEB system. An object of the present invention is to provide a variable amount transaction processing apparatus in a WEB system that can be used.

  In order to achieve the above object, the present invention accepts a variable amount of transaction, passes control to an application process that processes the transaction, asynchronously processes the transaction in its own process, and sends the processing result to the client terminal device. It is characterized by comprising means for notifying and means for notifying the console device of a failure when the application process is unjustly extinguished.

According to the present invention, the following effects can be obtained.
(1) The client terminal device that is the request source of the transaction is uniquely recognized on the server device, and the object state in the application process generated by the request source is managed. Even if there is the same transaction execution request after connection, it is possible to prevent multiple runs.
(2) While the application process is desynchronized and a transaction is being processed, an inquiry response type user interface can handle a large transaction by transmitting and receiving messages between the client terminal device and the server device at regular intervals. That is. That is, when handling a variable amount of transactions, processing can be realized without changing the user interface. Even when the transaction size is large (when processing on the server device takes time), it is not limited by the session timeout of the proxy server installed at the client site (the session is not disconnected).
(3) By monitoring the status of the desynchronized application process in a separate process, even if there is an abnormal termination that cannot be detected by the application process itself due to a program interrupt from the OS, no information remains as an invalid status. It is possible to notify the operator of trouble.

Hereinafter, an embodiment for carrying out the present invention will be specifically described with reference to the drawings. In addition, in each drawing, it demonstrates using the same code | symbol about the same component.
(1) First Embodiment FIG. 1 is a system configuration diagram of an embodiment of the present invention.
In FIG. 1, reference numerals 1, 2, and 3 denote client terminal devices that issue transactions, and are equipped with a browser.
Reference numeral 4 denotes a server device that accepts transactions from the client terminal devices 1 to 3 and executes processing.
The server apparatus 4 includes a request transmission / reception mechanism 200, an application process 310 that executes a transaction, an application process 320, and an application process 330.
A storage device 400 is shared among the request transmission / reception mechanism 200, the application process 310, the application process 320, and the application process 330, and includes “request source ID”, “process ID”, and “status (status)” as information.
The application process 310 has a process ID. The application process 310 generates an object in response to an object generation request from the client terminal device 1. The object includes an object ID, which is identification information, and a request source ID. The object generated here is transferred to the client 1 and used in subsequent transaction execution requests. The same applies to the application processes 320 and 330.

FIG. 2 is a block diagram for explaining a specific operation of the transaction execution method according to the present embodiment.
The object 510, the object 520, and the object 530 in FIG. 2 are generated by the application process 310, the application process 320, and the application process 330, respectively.
The object 610 in the client terminal device is the same as the object 510 in the server device.
Similarly, the object 620 is the same as the object 520, and the object 630 is the same as the object 530.
The client terminal device 1 issues an object generation request together with a request source ID to the server device 4 prior to transaction execution.
In the server apparatus 4, the request transmission / reception mechanism 200 receives this request.
After receiving the request, the request transmission / reception mechanism 200 determines an application process to be distributed. At this time, the storage device 400 is referenced to check whether the request source ID exists. If it does not exist, the application process ID and request source ID are set in the storage device 400.

On the other hand, if the request source ID exists and the status is “transaction in progress” (this means that a processing request has been previously made in the session different from the session from the same client terminal device). Then, the state is set to “discard”, and an application process ID and a request source ID are newly set.
Here, it is assumed that the request is distributed to the application process 310. The application process 310 generates the object 510 in response to the object generation request. Here, the own process ID is set as the object ID so that it can be identified by which application process it is generated. Thereafter, the application process 310 transmits the object 610 to the client terminal device 1 that is the generation request source via the request transmission / reception mechanism 200.
Thereafter, the client terminal device 1 makes a transaction execution request using the object 610.

The client terminal device 1 transmits a transaction execution request together with the object 610 to the server device 4.
When the request transmission / reception mechanism 200 in the server apparatus 4 receives the request, it determines an application process from the object ID set in the object information (here, the application process 310), and passes control to the application process 310.
The application process 310 under control performs transaction processing, but refers to the storage device 400 immediately before the synchronization point acquisition processing (here, the synchronization point processing refers to actual update of transaction data to the database, etc.) If the state of the application process ID is “transaction in progress”, synchronization point processing is performed and the transaction is completed.
On the other hand, if the state is “discard”, rollback processing is performed to invalidate the transaction. That is, it means that the session of the transaction has been disconnected for some reason, there is no return destination, and there has been a subsequent transaction execution request in another session from the same client terminal device 1. Therefore, the transaction is invalidated.
Such processing can prevent multiple transactions from the same client terminal device from running.

(2) Second Embodiment Secondly, a specific operation for executing a transaction requested by a client using an asynchronous application process will be described with reference to FIG.
In FIG. 3, 5 is a WEB server, which is in the server device 4.
The request transmission / reception function 200 includes a message reception processing unit 210, a transaction activation processing unit 220, message response processing units 230-1 and 230-2, and a state check processing unit 240.
Further, the application process 310 includes a transaction processing unit 311 and a processing state update processing unit 312.
The transaction execution request transmitted from the client terminal device 1 is received by the message reception processing unit 210 together with the transaction data.
When the received message is a transaction request, the message reception processing unit 210 passes control to the transaction activation processing unit 220.

The transaction activation processing unit 220 determines an application process from the object ID in the transaction data, and passes control to the application process 310 by inter-process communication. At this time, the transaction data is delivered to the application process 310 via the storage device 400-2. Further, upon activation, the state of the storage device 400-1 is updated to “transaction in progress”. From here, the request transmission / reception mechanism 200 and the application process 310 proceed asynchronously. The transaction activation processing unit 220 passes control to the application process and then passes control to the message response processing unit 230-1.
The message response processing unit 230-1 transmits a response indicating that “processing is in progress” to the client terminal device 1.

When the client terminal device 1 receives the message, the client terminal device 1 is in a waiting state for a certain period of time. At this time, a status of “processing” is displayed on the screen, so that a transaction is being executed for the operator. Let them know.
The client terminal device 1 makes a state inquiry request to the server device 4 without changing the screen state after a certain period of time, and the message reception processing unit 210 in the server device 4 receives this request, and controls the state check processing. To the unit 240.
The status check processing unit 240 refers to the storage device 400-1 to check the status of the transaction. If “transaction is being executed”, the client terminal device indicates that the message response processing unit 230-1 is “processing”. 1 is sent as a response.

On the other hand, the transaction processing unit 311 in the application process 310 controlled by the transaction activation processing 220 performs processing according to the transaction data (generally, business data update processing is performed here).
After the transaction processing ends, control is transferred to the processing state update unit 312, and the processing unit updates the state of the storage device 400-1 to “END”.
While the state of the storage device 400-1 is “processing”, the client terminal device 1 and the request transmission / reception mechanism 200 repeat the state inquiry request and the state response transmission, respectively.
When the state check processing unit 240 detects that the state of the storage device 400-1 is “finished”, the message response processing unit 230-2 transmits a response to that effect to the client terminal device 1, and displays it on the screen. Displays the end of the transaction. As a result, even when the transaction size is large, the processing can be completed without being limited by the session timeout by the proxy server installed at the client site.

(3) Third Embodiment A specific operation of monitoring an application process when a transaction is executed by an asynchronous application process will be described with reference to FIG.
In FIG. 4, reference numeral 700 denotes a process monitoring mechanism that is in the server apparatus 4 and has a function of monitoring the application process 310.
The storage device 400-3 has a mechanism for managing the state (starting or stopping) of the application process.
The console device 6 is an input / output device in which operations related to operation are performed by a center operator, and has a function of outputting a message to the effect when a failure occurs in the system.
In the request transmission / reception mechanism 200 that has received the transaction execution request from the client terminal device 1, control is passed to the application process 310 by the transaction activation processing unit 220 included in the mechanism, and the transaction processing unit 311 executes the transaction.
As described in the second embodiment, the state of the storage device 400-1 is updated to “transaction in progress” at this time.
The process monitoring mechanism 700 always refers to the storage device 400-1 at regular intervals, and obtains a process ID whose state is “transaction in progress” and whose monitoring state is “not yet” (310 in the figure). After obtaining the process ID, the life and death of the application process is monitored at regular intervals using the process ID. At this time, the monitoring state of the storage device 400-1 is updated to “being executed”.

Next, in FIG. 5, when the application process 310 disappears (abnormal termination) due to some factor, this is detected by the process monitoring mechanism 700, the state of the storage device 400-1 is set to “abnormal”, and the monitoring state is “not yet”. Update to
In addition, the application process management information in the storage device 400-3 is updated to the effect that the application process (310 in this case) cannot be used. Thereafter, the console device 6 is notified of the abnormality, and the console device 6 displays the fact on the screen after receiving the notification.
As a result, it is possible to notify the operation operator of the occurrence of the failure.

It is a system configuration figure of a first embodiment of the present invention. It is a block diagram for demonstrating operation | movement of the transaction processing apparatus which concerns on this embodiment. It is a block diagram for demonstrating the operation | movement performed with the application process which made the transaction asynchronous. It is a block diagram for demonstrating the specific operation | movement of the monitoring of the desynchronized application process. It is a block diagram for demonstrating specific operation | movement when the asynchronous application process lose | disappears.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Client terminal device, 2 ... Client terminal device, 3 ... Client terminal device, 4 ... Server device, 5 ... WEB server, 6 ... Console device, 200 ... Request transmission / reception mechanism, 210 ... Message reception processing part, 220 ... Transaction start-up Processing unit 230 ... Message response processing unit 240 ... Status check processing unit 310 ... Application process 320 320 Application process 330 ... Application process 311 ... Transaction processing unit 312 ... Processing status update processing unit 400 ... Storage device , 510 ... Object, 520 ... Object, 530 ... Object, 610 ... Object, 620 ... Object, 630 ... Object, 700 ... Process monitoring mechanism.

Claims (1)

A variable amount transaction processing apparatus in a WEB system,
A means of accepting a variable amount of transaction and passing control to the application process that processes the transaction, a means of processing the transaction asynchronously with its own process, and notifying the client terminal device of the processing result A variable amount transaction processing apparatus in a WEB system, characterized by comprising means for notifying the console apparatus of a failure in a case.

Images