WO2006080058A1 - 電文処理装置 - Google Patents

電文処理装置 Download PDF

Info

Publication number
WO2006080058A1
WO2006080058A1 PCT/JP2005/001014 JP2005001014W WO2006080058A1 WO 2006080058 A1 WO2006080058 A1 WO 2006080058A1 JP 2005001014 W JP2005001014 W JP 2005001014W WO 2006080058 A1 WO2006080058 A1 WO 2006080058A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
message processing
processing
request
processing request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2005/001014
Other languages
English (en)
French (fr)
Inventor
Kiyoshi Kimachi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to PCT/JP2005/001014 priority Critical patent/WO2006080058A1/ja
Priority to JP2007500371A priority patent/JPWO2006080058A1/ja
Publication of WO2006080058A1 publication Critical patent/WO2006080058A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues

Definitions

  • the present invention relates to a message processing device, and in particular, processes messages such as processing requests and event notifications simultaneously generated from a large number of clients such as WEB and online processing of financial distribution, large-scale network operation systems, and the like. It relates to a message processing device.
  • simultaneous parallel processing of messages is conventionally achieved by a system that performs load distribution using a plurality of processing devices.
  • Data that is referenced and updated in the process of processing messages is centralized in a file or database.
  • data reference and update (access) by the parallel processing compete with each other and become a bottleneck. For this reason, it is often the case that the processing performance is not improved more than expected because the effect of distributed processing is not obtained, and a complicated system configuration that synchronizes by providing many replicas of the file database for reference and update is provided. Had to take.
  • the depth of the standby tree considered when resolving a conflict is limited to a predetermined depth.
  • the current length of transaction T is based on the start time assigned to each global transaction. This start time is a parallel control method that also includes a start-up message for each sub-transaction (for example, see Patent Document 1).
  • Patent Document 1 JP-A-6-103132
  • Patent Document 2 JP 2000-293385 A
  • the present invention solves the problem of access contention in multiple distributed processing provided with a plurality of processing devices, so that a large number of simultaneous messages can be processed in real time, and the number of users on the client side
  • the purpose is to provide a message processing device with scalability that can handle the increase in the number of events and the increase in content capacity.
  • the message processing device receives messages and their message processing requests simultaneously from a plurality of clients, aggregates the message processing requests, and transmits the message processing.
  • a first means for storing all the messages related to the request in the input message storage device In response to the message processing request aggregated by the first means, the message processing request is further aggregated once or more, and the messages corresponding to the message processing request based on the aggregated message processing request are collectively collected from the input message storage device.
  • the message processing requests are aggregated. Each message is stored together in the input message storage device.
  • the second means further aggregates the message processing requests aggregated by the first means.
  • the number of times of aggregation may be one or more.
  • the messages corresponding to the collected message processing requests are collectively read from the input message storage device and processed.
  • the message processing state and message processing result can be inquired from the client at any time by the serial number notified when the message processing request is received from the client.
  • a message processing request is simultaneously received from a plurality of clients, the message processing request is primarily aggregated for each message type, and a message related to the message processing request is stored in the input message storage device.
  • a plurality of message accepting units that collectively store for each message type, and a message processing request unit that receives a second message processing request that is aggregated secondarily for each message type, and a plurality of client connection devices that each include A message processing request generated by each client connection device based on the message processing request, and a message processing request receiving unit that performs third order aggregation of the message processing requests, and a message processing request that is thirdarily aggregated from the message processing request receiving unit.
  • the message data corresponding to the message processing request is collectively read from the input message storage device, and a plurality of message processing units each performing processing corresponding to the message type are included.
  • a message processing device including a processing device for each sentence type.
  • the message processing device is roughly divided into a plurality of client connection devices 2 each connected to a plurality of clients 1 (hereinafter, this device may be referred to as a “server”), and each.
  • Each is composed of a plurality of processing devices 3 for each type of message connected to a plurality of client connection devices 2, and consists of four layers as follows.
  • the first hierarchy is a message reception unit Al_l, Al_2, Al_n (hereinafter may be collectively referred to as “A1”).
  • the second hierarchy is a message processing request unit A2
  • the third hierarchy is a message processing request reception unit.
  • A3_l and A3_2 (hereinafter collectively referred to as “A3”)
  • the last fourth layer is the message processing units A4_l and A4_2 (hereinafter sometimes collectively referred to as “A4”). is there.
  • Each of the plurality of clients 1 can exchange an event cl such as a message processing request and its response with the message reception unit A1 (first layer) of the client connection devices 2_1 and 2_2. .
  • each client connection device 2 the plurality of message reception units A1 of each client connection device 2 are connected so that the event c2 can be notified to the message processing request unit A2 (second layer).
  • each message processing request unit A2 is connected so that event c3 can be notified to each message processing request receiving unit A3 (third layer) of message type 1 processing device 3_1 and message type 2 processing device 3_2. It has been.
  • the message type 1 processing device 3_1 and the message type 2 processing device 3_2 are provided with a message processing unit A4 (fourth layer) according to the message type, and each message processing unit A4 has a corresponding message processing.
  • Request accepting section A3 can receive event c4.
  • each message reception unit A1 accesses the input message storage device 4 dl and accesses the processing result storage device 5 d2.
  • Each message processing unit A4 (fourth layer) connects to the input message storage device 4 to access d3, the management information storage device 6 to access d4, and the processing result storage device 5 to access d5. Has been.
  • a plurality of message reception units A1 of each client connection device 2 receive the event cl and receive their message data ( (Hereinafter, it may be simply referred to as “message”.) Is aggregated for each message type and written to the input message storage device 4 in a batch (access), and the message processing request is generated. This is aggregated for each message type (primary aggregation), and the message processing request event c2 is notified to the corresponding message processing request part A2.
  • aggregation is the conversion into information indicating that the message processing request has been made, and there is no summation of the number of cases. For example, if there are 100 message processing requests within a predetermined time period, it is not necessary to notify 100 in the message processing request event c2, but only the fact that there are 100 message processing requests is handled. Notify the message processing request part A2.
  • the definition of aggregation is the same.
  • Each message processing request unit A2 further aggregates message processing request events c2 notified from a plurality of message reception units A1 for each message type (secondary aggregation), and the message type according to the message type.
  • the message processing request event c3 is notified to the message processing request reception unit A3 of the message type 1 processing device 3_1 or message type 2 processing device 3_2 of each processing device 3.
  • Each message processing request accepting unit A3 that receives the message processing request event c3 from the message processing requesting unit A2 of each client connection device 2 performs the request receiving process and further aggregates them (tertiary aggregation). Then, the message processing request event c4 is notified to the corresponding message processing unit A4 to request processing of the message.
  • Each message processing unit A4 that has received the tertiary aggregated message processing request event c4 reads unprocessed message data from the input message storage device 4 in a batch based on the message processing request ( Access d3).
  • the management information necessary for the processing is referred to from the management information storage device 6 and updated (access d4), the message data is processed, and the processing results are stored in the processing result storage device 5 in a lump ( Access d5).
  • the message processing unit A4 corresponding to the message type receives one message from the input message storage device 4 in which the message receiving unit A1 collectively stores the messages related to the message processing request for each message type. Since a large amount of message data to be processed in a process is read and processed in a batch, there is no need to transfer the message data to be processed in a route that is aggregated and transferred step by step, and access contention can be extremely reduced. .
  • the message processing device provides a message processing unit as means for transmitting a large number of simultaneous message processing requests from each reception unit of the client connection device to each message processing unit of the message type processing device. Informing the request by expanding the scale of aggregation while consolidating requests in stages. This ensures scalability and solves the problem of access contention.
  • means for transmitting the above-mentioned large amount of message processing requests to each message processing unit that is, primary aggregation of each message reception unit, secondary aggregation of each message processing request unit, and tertiary aggregation of each message processing request reception unit
  • each message processing unit that is, primary aggregation of each message reception unit, secondary aggregation of each message processing request unit, and tertiary aggregation of each message processing request reception unit
  • the same effect can be obtained by adopting a configuration in which, in addition to each message type, for example, the contents of the message are aggregated step by step according to the function of the section.
  • Each message reception unit of the message processing device in (3) receives a confirmation request for each message type using the serial number from each client, and responds to the serial number from the input message storage device.
  • the corresponding message processing state can be read and responded to the client.
  • each message reception unit A1 receives a new message processing request cl_l from a plurality of clients 1 together with the message, the message numbering process for adding a sequence number to the message (hereinafter, “processing” is omitted). Force S.) Save al_l and save the message temporarily. Each message reception unit A1 executes this sequence number al_l (primary aggregation) until either the predetermined number of receptions or the predetermined time reaches first (primary aggregation). The messages containing the information associated with are stored in the input message storage device 4 al_2 (message storage dl_l).
  • the message reception unit A1 responds to each client 1 of the newly aggregated new request cl_l by sending a reception response al_3 all at once, thereby responding.
  • the message reception unit A1 makes a message processing request al_4, and notifies the message processing request unit A2 that a message to be processed has been generated by the message processing request c2.
  • the order of execution of this message processing request c2 and new reception response cl_2 can be either.
  • each of the message reception units A1 as the first hierarchy is sent from each client 1.
  • the new request cl_l is temporarily aggregated within a predetermined time or the number of cases while performing serial number al_l, and the temporarily stored messages including the serial number are bundled in the input message storage device 4. And save. Also, for each client 1, a new reception response cl_2 that notifies the serial number is returned.
  • Each of the message processing request unit and the message processing request receiving unit of the message processing device in (2) receives the message processing request and performs standby processing until a predetermined time. Therefore, it is possible to send each message processing request to the message processing request accepting unit and the message processing unit and to indicate that a message to be processed has been generated.
  • each client connection device 2 receives a plurality of message processing requests c2 that are primarily aggregated for each message type from a plurality of message reception units A1 in the same client connection device 2, they receive them. Executes standby processing a2_l within a predetermined time, further aggregates (secondary aggregation) for each message type, and then executes message processing request a2_2, thereby processing the message type corresponding to the message type Sends message processing request c3 to message processing request accepting section A3.
  • the message processing request accepting unit A3 of each processing device 3 for each message type receives the message processing requests c3 secondarily aggregated by the message processing requesting unit A2 from the plurality of client connection devices 2, and then receives them. Is performed for each message type by performing standby processing a3_l for a predetermined time, and then aggregated (tertiary aggregation), and then each message processing corresponding to that message type is executed by executing message processing request a3_2. Send message processing request c4 to part A4.
  • each message processing request unit A2 and each message processing request receiving unit A3 receive the message processing request c2 that is received by each message receiving unit A1 and is primarily aggregated for each message type, for each message type.
  • the scale of aggregation is expanded step by step with secondary and tertiary, and a message processing request c4 is notified to each message processing unit A4 corresponding to the message type.
  • a large number of events cl are aggregated step by step by each message reception unit Al, each message processing request unit A2, and further each message processing request reception unit A3 as one message processing request c4. It is transferred to the corresponding message processing unit A4.
  • the message processing unit of the message processing device in (4) reads all unprocessed messages stored in the input message storage device, and manages Refers to and updates information necessary for processing each message from the information storage device, processes each message, stores the processing results in a batch in the processing result storage device, and further supports the correspondence in the input message storage device The message can be updated as processed.
  • the message processing unit A4 of the processing device 3 for each message type receives the message processing request c4 that is thirdarily aggregated from the message processing request receiving unit A3, the message processing unit A4 executes unprocessed message batch acquisition a4_l using it as a trigger, Read all unprocessed messages stored in the input message storage device 4 Read unprocessed messages d3_l.
  • the message processing a4_2 is executed, and the management information necessary for processing each message is referred to / updated d4 from the management information storage device 6 to process each message data.
  • the process proceeds to a message process result saving process a4_3, and these process results are stored in the process result storage device 5 in a batch d5.
  • each message processing unit provided for each message type receives the message processing request.
  • the unprocessed messages stored in the input message storage device are collectively read, and the information necessary for processing each message is updated from the management information storage device.
  • Each electronic message is processed, the processing results are collectively stored in the processing result storage device, and the corresponding electronic message in the input message storage device is updated as processed.
  • the message reception unit A1 can read out from the input message storage device 4 and the processing result storage device 5 and respond to the requesting client in response to a status confirmation request or a result acquisition request from the client.
  • the message processing apparatus collectively accesses a large number of messages to be processed, so that the access contention does not exist within the aggregated unit, and access is made on a case-by-case basis. Compared to the conventional example, the number is extremely small.
  • message data is collectively stored in the message accepting unit A1 of the first layer, and only the third-ordered message processing request is transferred to the message type processing unit of the fourth layer, which is the last layer, in the middle.
  • message data is collectively stored in the message accepting unit A1 of the first layer, and only the third-ordered message processing request is transferred to the message type processing unit of the fourth layer, which is the last layer, in the middle.
  • message type processing unit of the fourth layer which is the last layer, in the middle.
  • the message reception unit of the message processing apparatus in (7) reads the processing result from the processing result storage device and responds to the client can do.
  • the message reception unit A1 executes processing status acquisition al_5, The message processing status acquisition dl_2 of the processing status data corresponding to the serial number is performed from the input message storage device 4.
  • the message reception unit A1 executes the processing status response al_6 based on the acquired processing status, and returns the status checking response cl_4 to the client 1 that has received the status checking request cl_3.
  • the client 1 sends a result acquisition request cl_5 including the serial number notified earlier.
  • the message reception unit Al executes processing result acquisition al_7, and acquires the message processing result acquisition d2 of the message corresponding to the serial number from the processing result storage device 5.
  • the message reception unit A1 executes the processing result response al_8, and returns a result acquisition response cl_6 to the client 1 that has received the result acquisition request cl_5 based on the acquired processing result of the message.
  • the message processing requests of the new request cl_l are primarily aggregated and notified to the message processing request unit A2, and finally Processed by the message processing unit of the processing device 3 for each message type, but the remaining status check request c and 3 (see (4) above) and the result acquisition request c and 5 for the message processing request, the message reception unit A1 Is completed by responding to the status confirmation response cl_4 and the result acquisition response cl_6 as described above.
  • the new request cl_l, the subsequent status confirmation request cl_3 and the result acquisition request cl_5, that is, the processing is localized to the message reception unit A1 and the message processing unit A4 according to the contents of the message processing. By doing so, it is not necessary for the message processing unit A4 to access the message processed by the message reception unit A1, so that it is possible to further reduce the contention for access to the data related to the processing.
  • the message processing device receives a large number of message processing requests that are simultaneously generated by each reception unit, stores these messages in the input message storage device, and aggregates the message processing requests. Each message processing unit is notified, and each message processing unit receives the aggregated message processing request and reads and processes unprocessed messages from the input message storage device in a batch. This has the advantage that the number of accesses to the database is minimized and access efficiency is improved.
  • each received message processing unit collects the messages stored in the input message storage device by each reception unit, based on the message processing request, the messages to be processed in the same input message storage device. Therefore, there is an advantage that the process of transferring the message data becomes unnecessary in the process of collecting the message processing requests step by step.
  • the message reception unit adds a serial number to a message processing request newly requested by the client and writes the message to the input message storage device at the same time, and at the same time sends a request source client. Since the serial number is notified to the client, it is possible to synchronize the request content on the client side and the processing content on the message processing device by proceeding with subsequent message processing using the sequence number as a key. .
  • the message processing unit processes a message processing request newly requested by each client, and the message reception unit processes a message processing request including the same serial number, thereby processing the message processed by the message reception unit. Since there is no need for the message processing unit to access, there is an advantage that it is possible to further reduce the access competition to the data related to the processing.
  • each of the message processing request unit and the message processing request reception unit receives a message processing request aggregated in the previous hierarchy, and performs standby processing until a predetermined time for each. Therefore, there is an advantage that the scale of aggregation can be easily expanded in stages.
  • the message processing unit refers to and updates the information necessary for processing each message from the management information storage device, processes each message data, and stores the processing results in the processing result storage device. Since the message is stored in a batch and the corresponding message in the input message storage device is updated as processed, the message reception unit and the input message storage device and the processing result according to the status confirmation request and result acquisition request from the client. It has the advantage of being able to read from the storage device and respond to the requesting client.
  • ffi shows an example of the configuration of the entire system, and the configuration is the same as that shown in Fig. 1 except for the reservation reception processing device 3_1 and the empty seat illumination processing device 3_2 of the processing device 3 for each message type.
  • This is the same as the system configuration. That is, the message type 1 processing device 3_1 and the message type 2 processing device 3_2 in Fig. 1 are changed to the reservation acceptance processing device 3_1 and the vacant seat inquiry processing device 3_2 in Fig. 5, respectively, as specific examples of message types.
  • the explanation is omitted because the system configuration in FIG. 5 is omitted.
  • FIG. 6 A processing flow from reception to response to a reservation reception request and a vacant seat inquiry request, which are message processing requests for each message type from a number of clients 1, will be described.
  • the reservation reception request cl_l and the vacant seat inquiry request cl_3, which are simultaneously generated from the clients 1_11, 1_12, and 1_13, are simultaneously received by the corresponding client response thread al_l together with the respective messages. Then, the serial numbering al_ll is performed to add a serial number to each request and its message.
  • Temporary storage area for reserved reception 10_1 and vacant seat inquiry message temporary storage area 10_2 (hereinafter “temporary storage area for each message type 10 ⁇ ⁇ 10_2”) are temporarily stored in each case.
  • each client response thread al_l moves to standby activation al_13, and passes control to the reservation reception waiting thread al_2 or the vacant seat inquiry waiting thread al_3 for each message type, and also moves to the completion waiting al_14 to make a reservation.
  • the system waits until a message processing request transmission completion is received from the reception waiting thread al_2 or the vacant seat inquiry waiting thread al_3.
  • each electronic document containing al_23, al_33 writes the messages previously stored in the corresponding temporary storage areas 10_1, 10_2 for each message type into the input message storage device 4 (access dl_w). Thereafter, the processing moves to the corresponding message processing request transmission al_24, al_34.
  • each message processing request transmission al_24 and al_34 the fact that there is a message to be processed is sent to the corresponding message processing request unit A2 as a reservation acceptance message processing request c2_l and a vacant seat inquiry message processing request c2_2.
  • the completion of the message processing request al_24, al_34 is notified to the client response thread al_l in the completion wait al_14 state.
  • the client response thread al_l moves from the completion wait al_14 state to the acceptance response al_15, and the clients 1_11 and 1_12 Returns a reservation acceptance response cl_2 and a vacant seat inquiry response cl_4 to the client 1_13, together with the corresponding serial number.
  • the first-tier message reception unit A1 receives the message data received in a predetermined number of times or within a predetermined time for a large number of message processing requests generated simultaneously from a plurality of clients.
  • Temporary storage area 10 ⁇ 10_2 provided for each message type is temporarily stored with a serial number, and these are stored in the input message storage device 4 (access dl_w) at the same time, and the message processing is primarily aggregated for each message type
  • the request (reservation reception message processing request C 2_l, vacant seat inquiry message processing request c2_2) is notified to the corresponding second-layer message processing request unit A2.
  • the message reception unit A1 notifies the corresponding clients 1 of the serial numbers by responses cl_2 and cl_4. These serial numbers are used until one transaction is completed, that is, until the client 1 that has acquired the serial number acquires and completes the processing status confirmation and processing result described below.
  • the message reception unit A1 adds the message processing request newly requested from each client together with the message to the message number processing for each type and the predetermined number or predetermined number.
  • the message is temporarily stored in the standby process that waits until the time is reached, and when a certain number of messages or a certain time is reached, the messages stored up to that point are written in the input message storage device together with the serial number and requested.
  • the serial number is returned to the original client.
  • the message processing apparatus side uses the serial number acquired in the new reception response cl_2. By proceeding with the message processing using the same serial number as a key, it is possible to synchronize the request content on the client side and the processing content on the message processing device side.
  • the client response thread al_l executes the status read al_16 and the input message storage device 4 Reads the processing status corresponding to the serial number (access dl_r), and then executes status response al_17.
  • the client 1_11 that had the reservation status check cl_5 responded to the reservation status response cl_6, and the client 1_13 that had the query status check cl_9 responded to the query status response cl_10. Inform progress.
  • Clients 1_11 and 1_13 that have received a response that has already been processed can continue to request reservation result acquisition cl_7 and inquiry result acquisition cl_ll using the serial numbers.
  • each client response thread al_l receives reservation result acquisition cl_7 and inquiry result acquisition cl_l l from clients 1_11 and 1_13, each executes result read al_18 and corresponds to the serial number from processing result storage device 5 Read the reservation processing result (access d2_r), and then execute the result response al_19.
  • the serial number is acquired by the new reception response cl_2 from the message reception unit A1, and the subsequent message processing status inquiry When requesting acquisition of results, etc., use the serial number.
  • the message processing device side proceeds with message processing using the same serial number as the key, and keeps the request number on the client side synchronized with the processing content on the message processing device side and keeps the serial number until one processing is completed. Use to process.
  • the message reception unit A1 primarily aggregates the reservation reception request cl_l and the vacant seat inquiry request cl_3 for each message type and notifies the next hierarchy, and checks other reservation status cl_5, reservation Result acquisition For cl_7 and inquiry status confirmation cl_9 and inquiry result acquisition cU l, the message reception unit A1 reads out the processing status or result corresponding to the serial number from the input message storage device 4 or processing result storage device 5 and responds. To do.
  • the reception thread a2_l of the message processing request unit A2 receives a reservation reception message processing request c2_10 from the message reception unit A1, and generates a generation flag indicating that a reservation reception message has occurred.
  • Flag setting a2_l l Is set in the reservation acceptance message generation flag 20_1.
  • the generation flag setting a2_l l sets the generation flag to avoid multiple activation of the reservation acceptance standby thread a2_2 After confirming that the flag is OFF before setting, set (set) it to ON and move to stand-by activation a2_12.
  • the standby activation a2_12 activates the reservation reception standby thread a2_2 only when the generation flag is set from the OFF state to the ON state. If the generation flag is ON, the reservation acceptance standby thread a2_2 has already been started and will not start.
  • the reception thread a2_3 shows a case where the reservation reception message processing request c2_l l is received when the reservation reception message generation flag 20_1 is ON, the generation flag setting a2_l l of the reception thread a2_3 is not executed, and Since the reservation acceptance standby thread a2_2 does not start, the solid line with an arrow from the standby activation a2_12 to the reservation acceptance standby thread a2_2 is shown.
  • the activated reservation acceptance standby thread a2_2 performs temporary standby a2_13, and waits for a predetermined time, and when that time elapses, the process proceeds to message processing request transmission a2_14.
  • Transmission of message processing request a2_14 notifies the message processing request reception unit A3_l (see Fig. 5) of the reservation reception processing device 3_1 that there is a message to be processed (event c3_l), and then activates flag release a2_15 To do.
  • Flag release a2_15 sets the occurrence flag of the reservation acceptance message generation flag 20_1 to the release (OFF) state.
  • the generation flag setting a2_ll sets the generation flag indicating that the vacant seat inquiry message has occurred to the vacant seat inquiry message generation flag 20_2.
  • the occurrence flag setting a2_l l is set to OFF before setting the occurrence flag in the same way as when the reservation acceptance standby thread a2_2 is activated to avoid multiple activation of the vacant seat inquiry standby thread a2_5. After confirming that it is in the ON state, set it to the ON state and shift to stand-by activation a2_12.
  • the reception thread a2_6 shows a case where a vacant inquiry message processing request c2_21 is received when the vacant inquiry message generation flag 20_2 is ON, the generation flag setting a2_l l of the reception thread a2_6 is not executed, and Since the inquiry standby thread a2_5 also does not start, the solid line with an arrow from the standby startup a2_12 to the reservation reception standby thread a2_2 is shown.
  • the activated vacant seat inquiry waiting thread a2_5 performs temporary standby a2_13, and waits for a predetermined time, and when that time elapses, the process proceeds to message processing request transmission a2_14.
  • Transmission of message processing request a2_14 notifies the message processing request reception unit A3_2 (see Fig. 5) of the vacancy inquiry processing device 3_2 that there is a message to be processed (event c3_2), and then activates flag release a2_15 To do.
  • Flag release a2_15 sets the occurrence flag of the reservation acceptance message generation flag 20_2 to the release (OFF) state.
  • the message processing request unit A2 has a message processing request (event c2) primarily aggregated for each message type by each message reception unit A1, for example, a predetermined standby time (for example, 0.5 seconds). Are further aggregated (secondary aggregation) and notified to the message processing request accepting unit A3 corresponding to each message type as a message processing request (event c3).
  • message processing request receiving unit A3_l Upon receipt of message processing request c3_10 from message processing request unit A2, message processing request receiving unit A3_l receives thread a3_l and sets the flag that indicates that a message processing request has occurred.
  • the reservation acceptance processing generation flag 30_1 is set by l and standby activation a3_12 is performed. However, the generation flag setting a3_ll is set to ON only when the generation flag is OFF, and shifts to standby activation a3_12 in order to avoid multiple activation of the reservation acceptance standby thread a3_2.
  • the standby activation a3_12 activates the reservation acceptance processing standby thread a3_2 only when the generation flag is set from the OFF state to the ON state. If the reservation acceptance process occurrence flag 30_1 is ON, the reservation acceptance process standby thread a3_2 has already been activated and will not be activated further.
  • the reception thread a3_3 shows the case where the message processing request c3_ll is received when the reservation reception processing generation flag 30_1 is ON. In this case, the reservation reception processing standby thread a3_2 is not activated. In a sense, the standby activation a3_12 to the reservation reception processing standby thread a3_2 with an arrow The solid line has been removed.
  • the activated reservation acceptance processing standby thread a3_2 performs temporary standby a3_13.
  • the standby reception time a3_13 for example, waits for a predetermined time and the time elapses, the process proceeds to message processing request transmission a3_14.
  • Transmission of message processing request a3_14 notifies the message processing unit A4_l (see Fig. 5) of the reservation acceptance processing device 3_1 that there is a message to be processed (event c4_l), and then activates flag release a3_15. .
  • Flag release a3_15 releases the reservation acceptance processing occurrence flag of the reservation acceptance message generation flag 30_1 and turns it OFF.
  • the processing flow for accepting the message processing request for vacant seat inquiry is partly the same as when receiving the message processing request for reservation reception (the message processing request accepting unit A3_l). The same applies except for the above.
  • the generation flag setting of the reception thread a3_4 a3_ll processing power S, the generation flag indicating that a vacant seat inquiry message has been set to the vacant seat processing flag 30_2, and the vacant seat processing waiting thread a3_5 The processing flow is the same as the processing for accepting the message processing request for reservation reception described above, except that the message processing unit A4_2 (see Fig. 5) for vacant seat inquiry notifies that there is a message to be processed (event c4_2). . Also, the reception thread a3_6 indicates that it has not started the vacant seat inquiry processing waiting thread a3_5 because it received the message processing request c3_21 when the vacant seat processing flag 30_2 is ON. It is the same.
  • the message processing request unit A2 and the message processing request receiving unit A3 shown in FIGS. 8 and 9 respectively receive the message processing request, the corresponding message processing request is generated.
  • the message occurrence flag and the process occurrence flag are set to the “N” state. Set and perform standby processing until a predetermined time, send a message processing request collected by each to the message processing request reception unit and the message processing unit to notify that a message to be processed has occurred and Return both flags to the OFF state.
  • the reservation reception processing device 3_1 and the vacancy inquiry processing device 3_2 are listed as belonging to the processing device 3 for each message type.
  • the processing unit A4_l corresponds to the message processing unit for reservation reception
  • the message processing unit A4_2 corresponds to the message processing unit for vacant seat inquiry.
  • the message processing unit A4_l when the message processing unit A4_l receives a processing request c4_l such as a status confirmation request or a result acquisition request from the message processing request receiving unit A3_l, it performs unprocessed reservation reception message batch reading a4_l l and stores the input message Reads all unprocessed reservation acceptance messages from device 4 (access d3_r). Whether or not the message has been processed can be known by each message processing unit A4 updating the processing state of the input message storage device 4 after the message processing.
  • a processing request c4_l such as a status confirmation request or a result acquisition request from the message processing request receiving unit A3_l
  • the message processing unit A4_l reads the reservation information a4_12 to reference the reservation information in the management information storage device 6 (access d4_r), updates the reservation result registration a4_13 (access d4_w), and then updates the message. Perform the process.
  • the processing result is stored in the processing result storage device 5 by the message processing result registration a4_14 (access d5_w), and the corresponding processing status of the input message storage device 4 is updated by the next message processing status update a4_15 (access d3_w). )
  • the message processing unit A4_2 receives the processing request c4_2 from the message processing request receiving unit A3_2, the unprocessed empty seat inquiry message batch read a4_21 is executed and the unprocessed empty seat inquiry message is received from the input message storage device 4.
  • the vacant seat information reading a4_22 refers to the vacant seat information in the management information storage device 6 (access d4_r), and the processing result is stored in the processing result storage device 5 in the message processing result registration a4_23 (access d5_w).
  • update the message processing state a4_24 to update the corresponding processing state of the input message storage device 4 (access d3_w) and end the series of processing.
  • the message processing unit A4 receives the message processing requests aggregated in stages, reads the unprocessed messages stored in the input message storage device 4 at once, and manages them. Refer to and update information necessary for processing each message from the information storage device 6, process each message data, store the processing results in a batch in the processing result storage device 5, and further input message storage device 4 The corresponding message of is updated as processed. Accordingly, the message reception unit Al can read out from the input message storage device 4 and the processing result storage device 5 in response to a status confirmation request or a result acquisition request from the client and respond to the requesting client.
  • the message processing apparatus aggregates and processes a large number of messages simultaneously generated from a plurality of clients, so the number of accesses to files and databases is minimized, and access efficiency is increased. Can improve the processing of messages efficiently.
  • the access conflict for data reference / update by the parallel processing does not become a botnoreneck, and the effect of the multiple distributed processing can be easily obtained.
  • aggregation of message processing requests in stages is not limited to tertiary aggregation, and cost performance is optimized by arbitrarily scaling the aggregation scale according to the requirements of the message processing device. It is also possible.
  • the message processing apparatus is not limited to the ticket reservation system shown in this embodiment, but also from many clients such as the online processing of WEB and finance 'distribution, and the operation system of a large-scale network. It can be applied to a message processing system that processes messages such as processing requests and event notifications in real time.
  • FIG. 1 is a block diagram showing the principle (system configuration) of a message processing device according to the present invention.
  • FIG. 2 is a block diagram showing the principle (message reception unit) of the message processing device according to the present invention.
  • FIG. 3 is a block diagram showing the principle (message processing request unit / message processing request receiving unit) of the message processing device according to the present invention.
  • FIG. 4 is a block diagram showing the principle (message processing unit) of the message processing device according to the present invention.
  • FIG. 5 is a block diagram showing an embodiment (ticket reservation system configuration) of a message processing apparatus according to the present invention.
  • FIG. 6 is a block diagram showing an embodiment (1/2 of the message reception unit) of the message processing apparatus according to the present invention.
  • FIG. 7 is a block diagram showing an embodiment (2/2 of the message reception unit) of the message processing apparatus according to the present invention.
  • FIG. 8 is a block diagram showing an embodiment (message processing request unit) of the message processing device according to the present invention.
  • FIG. 9 is a block diagram showing an embodiment (message processing request accepting unit) of the message processing device according to the present invention.
  • FIG. 10 is a block diagram showing an embodiment (message processing unit) of the message processing device according to the present invention. Explanation of symbols

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

　複数クライアント１から同時大量に発生する電文処理要求c1を、各クライアント接続装置２では複数の受付部A1で電文種別毎に一次集約すると共に電文処理要求c1の電文を入力電文記憶装置４に一括格納し、更に該一次集約した電文処理要求c2を電文処理要求部A2で二次集約して電文種別毎処理装置３に電文処理要求c3として転送する。電文種別毎処理装置３では複数のクライアント接続装置２から電文処理要求c3を、電文種別毎の電文処理要求受付部A3が受け付けて更に三次集約し、対応する電文種別毎の電文処理部A4に電文処理要求c4として電文処理の要求が発生したことを通知する。電文処理要求c4を受けた電文処理部A4は、入力電文記憶装置４から未処理の電文データを一括して読み出して対応した処理を行う。クライアントからは、受付部A1にて電文処理要求を受付けた際に通知した通番により、随時、電文の処理状態の確認や処理結果の取得を行う。

Description

明 細 書
電文処理装置
技術分野
[0001] 本発明は、電文処理装置に関し、特に WEBや金融'流通のオンライン処理、大規 模ネットワークのオペレーションシステム等の多数のクライアントから同時に発生する 処理要求やイベント通知等の電文をリアルタイムに処理する電文処理装置に関する ものである。
背景技術
[0002] ネットワークに接続されたクライアント（エンドユーザー端末や装置等）から同時多発 する大量の電文（処理の要求やイベント通知等）をリアルタイムに処理するシステムに おいては、電文単位にそれを処理するタスクを割り当てて、各電文に対する処理を同 時並行で多重処理することになる力 この場合、処理の多重度に応じて、システム資 源は比例して大きくしなければならなかった。
[0003] また、電文の同時並行処理は、従来より、複数の処理装置を用いて負荷分散を行う システムにより実現されている力 電文の処理過程において参照 ·更新するデータを ファイルやデータベース等で一元管理する場合、その並行処理によるデータ参照 . 更新 (アクセス）が相互に競合し合いボトルネックとなる。このため、分散処理の効果 が得られずに処理能力が期待されたより向上しない場合が多ぐ参照 ·更新を行うフ アイルゃデータベースの複製を多数設けて、同期化させるような複雑なシステム形態 を採らなければならなかった。
[0004] 一方、マルチ ·ユーザー ·データ処理環境において使用される待機深さの制限並行 制御として、競合関係を解決する際に考慮する待機木の深さを、予め決められた深 さに制限する方法がある。これは、集中トランザクション処理システムへの実施例にお いては、実数関数によって代表されるトランザクション特有の情報が、予め決められた 深さを超えたトランザクション間のコンフリクトの場合に、どのトランザクションを再始動 するかを決めるのに使用され、分散トランザクション処理システムでは、トランザクショ ン Tの現在の長さは，各大域トランザクションに割り当てられた開始時間に基づいて おり、この開始時間には各サブトランザクションのスタートアップ'メッセージも含んで いる並行制御方法である（例えば、特許文献 1参照。）。
[0005] さらに、所定数のスレッドが生成され、その情報がスレッド惰報記憶部に登録され、 生成されたスレッドの内、空きスレッドが空きスレッドリストに登録され、外部からのスレ ッドを必要とする処理要求が待機リストに登録され空きスレッドリストを監視して空きス レッドの発生を待って処理を実行すると共に、外部からのスレッドを必要としない処理 要求は待機リストを介さずに受け付けられ処理を実行するスレッド管理システム及び 管理方法並びに管理プログラムを記録した記録媒体がある（例えば、特許文献 2参 照。）。
特許文献 1 :特開平 6-103132号公報
特許文献 2：特開 2000-293385号公報
発明の開示
発明が解決しょうとする課題
[0006] このように、並行処理でのファイルやデータベースへのアクセス競合が想定されるシ ステムにおいては、これらの競合を回避しなければ、例え複数の処理装置を設けて 多重分散処理を行っても、その並行処理によるデータ参照 '更新のためのアクセス競 合がボトルネックとなるため、その多重分散処理の効果が得られなかった。
[0007] また、そのアクセス競合を回避するためには、参照 ·更新を行うファイルやデータべ ースの複製を多数設けて、それらを自動的に同期化させるような複雑なシステム形態 を採らなければならなかった。
[0008] 従って本発明は、複数の処理装置を設けた多重分散処理におけるアクセス競合の 課題を解決することにより、同時多発する大量の電文をリアルタイムに処理でき、且 つ、クライアント側のユーザ数やイベント数の増力 0、コンテンツの大容量化に対応可 能な、スケーラビリティを確保した電文処理装置を提供することを目的とする。
課題を解決するための手段
[0009] (1)上記の課題を解決するため、本発明に係る電文処理装置は、複数のクライアン トから同時に電文及びその電文処理要求を受け付けて該電文処理要求を集約する と共に、該電文処理要求に係る電文を、入力電文記憶装置に一括格納する第 1手段 と、該第 1手段で集約した電文処理要求を受けて更に一回以上集約すると共に、該 集約した電文処理要求に基づき該電文処理要求に対応した電文を、該入力電文記 憶装置から一括して読み出して対応した処理を行う第 2手段とを備え、クライアント力 らの電文処理要求を受付けた時に通知した通番により、クライアントから電文処理状 態や電文処理結果を随時、照会可能としたことを特徴としてレ、る。
[0010] すなわち、第 1手段では、複数のクライアントが同時に電文とその電文処理要求又 は依頼 (以下、「要求」と総称する。）を送出したとき、その電文処理要求を集約し、さ らに各電文を入力電文記憶装置に一括して格納しておく。
[0011] そして、第 2手段では、上記第 1手段で集約した電文処理要求をさらに集約する。こ の時の集約回数は 1回以上であればよい。そして、このように集約した電文処理要求 に基づいて対応した電文を、入力電文記憶装置から一括して読み出して処理を行う
[0012] そして、クライアントからの電文処理要求を受付けた時に通知した通番により、クライ アントから電文処理状態や電文処理結果を随時、照会可能としたものである。
[0013] このようにして、電文自体は入力電文記憶装置に格納しておき、電文処理要求の みを集約してから電文処理を行うので、入力電文記憶装置へのアクセス競合状態を 排除することが可能になると共に、不要な電文の転送処理を排除することができる。
[0014] (2)また、本発明では、複数のクライアントから同時に電文処理要求を受け付けて 該電文処理要求を電文種別毎に一次集約すると共に、該電文処理要求に係る電文 を入力電文記憶装置に電文種別毎に一括格納する複数の電文受付部、及び該ー 次集約した電文処理要求を受けて、電文種別毎に更に二次集約する電文処理要求 部を、各々が含む複数のクライアント接続装置と、該電文処理要求に基づき各クライ アント接続装置で生成された電文処理要求を受けて、それらを更に三次集約する電 文処理要求受付部、及び該電文処理要求受付部から該三次集約した電文処理要 求を受けて、該電文処理要求に対応した電文データを、該入力電文記憶装置から 一括して読み出し該電文種別に対応した処理を行う電文処理部を、各々が含む複 数の電文種別毎処理装置と、を備えた電文処理装置が提供される。
[0015] ここで、上記（2)の原理を、図 1を参照して以下に説明する [0016] まず、本発明に係る電文処理装置は大略、各々が複数のクライアント 1に接続され た複数のクライアント接続装置 2 (以下、この装置を「サーバ」と呼ぶことがある。）と、各 々が複数のクライアント接続装置 2に接続された複数の電文種別毎処理装置 3とで構 成されており、次のように 4階層力、ら成っている。
[0017] 第 1階層は電文受付部 Al_l、 Al_2、 Al_n (以下、符号「A1」で総称することがある。 ) 、第 2階層は電文処理要求部 A2、第 3階層は電文処理要求受付部 A3_l及び A3_2 (以 下、符号「A3」で総称することがある。）、そして最後の第 4階層は電文処理部 A4_l及 び A4_2 (以下、符号「A4」で総称することがある。）である。
[0018] 複数のクライアント 1は、それぞれがクライアント接続装置 2_1、 2_2の電文受付部 A1 ( 第 1階層）との間で電文処理要求やその応答等のイベント clの授受ができるようにな つている。
[0019] また、各クライアント接続装置 2の複数の電文受付部 A1は、イベント c2を電文処理要 求部 A2 (第 2階層）に通知できるように接続されている。
[0020] 更に、各電文処理要求部 A2は、イベント c3を、電文種別 1処理装置 3_1及び電文種 別 2処理装置 3_2の各電文処理要求受付部 A3 (第 3階層）に通知できるように接続さ れている。
[0021] 電文種別 1処理装置 3_1及び電文種別 2処理装置 3_2には、その電文種別に応じた 電文処理部 A4 (第 4階層）が設けられており、各電文処理部 A4は対応する電文処理 要求受付部 A3からイベント c4を受けられるようになってレ、る。
[0022] 一方、電文処理に係る電文データへのアクセスにつレ、ては、各電文受付部 A1 (第 1 階層）が入力電文記憶装置 4にアクセス dl、処理結果記憶装置 5にアクセス d2を行い 、各電文処理部 A4 (第 4階層）が入力電文記憶装置 4にアクセス d3、管理情報記憶装 置 6にアクセス d4、処理結果記憶装置 5にはアクセス d5ができるように、それぞれが接 続されている。
[0023] 上記の構成において、複数のクライアント 1から電文処理要求のイベント clがあると 、各クライアント接続装置 2の複数の電文受付部 A1が、そのイベント clを受けて、それ らの電文データ（以下、単に「電文」と呼ぶ場合がある。）を電文種別毎に集約して入 力電文記憶装置 4に一括して書き込む（アクセス ）と共に、該電文処理要求が発生 した事を電文種別毎に集約し (一次集約）、対応する電文処理要求部 A2に向けて、 電文処理要求のイベント c2を通知する。
[0024] なお、集約とは、該電文処理要求があったことを示す情報に変換することであり、そ の件数を合計することでは無レ、。例えば、予め定めた時間内に 100件の電文処理要 求があつたとすると、電文処理要求のイベント c2で 100件と通知するのでは無ぐ 100件の電文処理要求があった事実のみを対応する電文処理要求部 A2に知らせる 。以下、集約についての定義は、同様である。
[0025] 各電文処理要求部 A2は、複数の電文受付部 A1から通知された電文処理要求のィ ベント c2を電文種別毎に更に集約し (二次集約）、その電文種別に応じて電文種別 毎処理装置 3の電文種別 1処理装置 3_1又は電文種別 2処理装置 3_2の電文処理要 求受付部 A3に向けて、電文処理要求のイベント c3を通知する。
[0026] 各クライアント接続装置 2の電文処理要求部 A2から電文処理要求のイベント c3を受 けた各電文処理要求受付部 A3は、各々がその要求の受付処理を行って更に集約し (三次集約）、対応する電文処理部 A4に電文処理要求のイベント c4を通知してその 電文の処理を要求する。
[0027] 該三次集約された電文処理要求のイベント c4を受けた各電文処理部 A4は、該電文 処理要求に基づき、入力電文記憶装置 4から未処理の電文データを一括して読み出 す（アクセス d3)。なお、その処理に必要な管理情報を管理情報記憶装置 6から参照' 更新（アクセス d4)して、それらの電文データを処理し、その処理結果を処理結果記 憶装置 5へ一括して格納（アクセス d5)する。
[0028] 従って、電文種別に対応した電文処理部 A4は、該電文受付部 A1が該電文処理要 求に係る電文を電文種別毎に一括格納した該入力電文記憶装置 4から、一度のァク セスで処理対象となる大量の電文データを一括して読み出して処理するので、段階 的に集約して転送する経路での処理対象電文データの転送が不要となり、アクセス 競合を極めて少なくすることができる。
[0029] また、本発明に係る電文処理装置は、同時多発した大量の電文処理要求をクライ アント接続装置の各受付部から電文種別毎処理装置の各電文処理部に伝える手段 として、該電文処理要求を段階的に集約しながら、集約規模を拡大して通知すること により、スケーラビリティを確保すると共にアクセス競合の問題を解決している。
[0030] 従って、上記の大量の電文処理要求を各電文処理部に伝える手段、すなわち、各 電文受付部の一次集約、各電文処理要求部の二次集約及び各電文処理要求受付 部の三次集約は、機能的のみならず物理的境界等を考慮して段階的に集約する手 段の一つであり、上記の原理説明に限定されるものではなぐその電文処理要求を、 一括処理する電文処理部の機能に沿って、電文種別毎の他に、例えば、電文内容 毎等で段階的に集約する構成を採ることでも同じ効果が得られる。
[0031] (3)上記（2)における電文処理装置の各電文受付部は、該クライアントから新規に 要求された電文及びその電文処理要求に通番を付加する通番処理と、予め定めた 件数又は予め定めた時間になるまで該電文を一旦保存し、該件数又は該時間に達 した時、それまで保存した電文を該通番と共に該入力電文記憶装置に一括して書き 込み、要求元のクライアントには該通番を通知することができる。
[0032] (4)上記（3)における電文処理装置の各電文受付部は、各クライアントから該通番 を用いた電文種別毎の確認要求を受けた時、該入力電文記憶装置から該通番に対 応する電文処理状態を読み出して該クライアントに応答することができる。
[0033] ここで、上記（3)及び (4)の原理を、図 2を参照して以下に説明する
[0034] 各電文受付部 A1は、複数のクライアント 1から新規の電文処理要求 cl_lをその電文 と共に受けると、その電文に通番を付加する通番採番処理（以下、「処理」を省略す ること力 Sある。）al_lを行レ、、その電文を一時保存する。各電文受付部 A1は、予め定 めた受付件数又は予め定めた時間の何れかが先に達するまで、この通番採番 al_lを 実行すると（一次集約）、それまで一時格納したその通番若しくはその通番に関連付 けた情報を含んだ電文を入力電文記憶装置 4へ一括格納 al_2する（電文格納 dl_l)。
[0035] 次に、電文受付部 A1はここで一次集約された新規要求 cl_lの各クライアント 1に対 して、一斉に受付応答 al_3を行うことにより、それぞれの新規受付応答 cl_2を返して 対応する通番を通知し、続いて、電文受付部 A1は電文処理要求 al_4を行い、電文 処理要求部 A2へ処理対象の電文が発生したことを電文処理要求 c2で通知する。な お、この電文処理要求 c2と新規受付応答 cl_2の実行順序はどちらが先でもよい。
[0036] このようにして、第 1階層である電文受付部 A1の各々は、各クライアント 1から送られ て来た新規要求 cl_lを、通番採番 al_lを行いながら予め定められた一定時間内又は 件数内で一次集約すると共に、その通番を含めて一時格納された電文を入力電文 記憶装置 4に一括して保存する。また、各クライアント 1に対しては、その通番を通知 する新規受付応答 cl_2を返す。
[0037] 従って、その後、電文種別毎の確認要求を受けたとき、入力電文記憶装置 4からそ の通番をキーとして、電文処理状態を読み出してクライアントに応答することで、クラ イアント側の要求内容と電文処理装置側の処理内容との同期処理が可能となる。
[0038] (5)上記（2)における電文処理装置の電文処理要求部及び電文処理要求受付部 は、それぞれ、該電文処理要求を受けて、それぞれに予め定められた時間まで待受 処理を行うことにより各集約を行レ、、各々が集約した電文処理要求をそれぞれ該電 文処理要求受付部及び該電文処理部へ送って処理対象の電文が発生したことを通 矢口すること力 Sできる。
[0039] 次に、上記（5)の原理を、図 3を参照して説明する
[0040] 各クライアント接続装置 2の電文処理要求部 A2は、同じクライアント接続装置 2内の 複数の電文受付部 A1から電文種別毎に一次集約された複数の電文処理要求 c2を 受けると、それらを、予め定めた一定時間内で待受処理 a2_lを行い、電文種別毎に 更に集約（二次集約）し、その後、電文処理要求 a2_2を実行することにより、電文種別 に対応した電文種別毎処理装置 3の電文処理要求受付部 A3へ電文処理要求 c3を 通知する。
[0041] 次に、各々の電文種別毎処理装置 3の電文処理要求受付部 A3は、電文処理要求 部 A2で二次集約された電文処理要求 c3を複数のクライアント接続装置 2から受けると 、それらを、予め定めた一定時間の待受処理 a3_lを電文種別毎に行って更に集約（ 三次集約）し、その後、電文処理要求 a3_2を実行することにより、その電文種別に対 応した各々の電文処理部 A4へ電文処理要求 c4を通知する。
[0042] このようにして、各電文処理要求部 A2と各電文処理要求受付部 A3は、各電文受付 部 A1で受け付けられ電文種別毎に一次集約された電文処理要求 c2を電文種別毎 に、二次及び三次と段階的に集約規模を拡大し、その電文種別に対応した各々の 電文処理部 A4へ電文処理要求 c4として通知する。 [0043] このようにして、大量のイベント clは、各々の電文受付部 Al、各電文処理要求部 A2 、更に各電文処理要求受付部 A3によって段階的に集約し、一つの電文処理要求 c4 として対応する電文処理部 A4に転送される。
[0044] 従って、その電文処理要求 c4内の電文処理におけるアクセス競合が無くなると共に 、処理件数当たりのファイルやデータベースへのアクセス回数が極めて少なくなり、ァ クセス効率が向上するので、クライアント数やイベント数の増加に柔軟に対応できる。
[0045] (6)上記（5)における電文処理装置の電文処理要求部及び電文処理要求受付部 は、それぞれ、該電文処理要求を受けると、対応する電文処理要求が発生したことを 示す電文発生フラグ、及び電文の処理要求が発生したことを示す処理発生フラグが OFF状態であることを各々が確認したときのみ該電文発生フラグ、及び該処理発生フ ラグを ON状態に設定し予め定められた時間まで該待受処理を行レ、、各々が集約し た電文処理要求をそれぞれ該電文処理要求受付部及び該電文処理部へ送って処 理対象の電文が発生したことを通知すると共に、両フラグを OFF状態に戻すことがで きる。
[0046] (7)上記（4)における電文処理装置の電文処理部は、該電文処理要求を受けて、 該入力電文記憶装置に格納されている未処理の電文を一括して読み出すと共に、 管理情報記憶装置から各電文の処理に必要な情報を参照 ·更新して各電文を処理 し、それらの処理結果を処理結果記憶装置に一括して格納し、更に該入力電文記憶 装置中の対応する電文を、処理済として更新することができる。
[0047] 次に、上記（7)の原理を、図 4を参照して説明する
[0048] 電文種別毎処理装置 3の電文処理部 A4は、電文処理要求受付部 A3から三次集約 された電文処理要求 c4を受けると、それをトリガーとして、未処理電文一括取得 a4_l を実行し、入力電文記憶装置 4に格納されている未処理の電文を一括して読み出す 未処理電文読出 d3_lを行う。次に、電文処理 a4_2の実行に移り、管理情報記憶装置 6から各電文の処理に必要な管理情報を参照 ·更新 d4をして、各電文データを処理 する。電文処理 a4_2が終了すると、電文処理結果保存処理 a4_3に移り、それらの処理 結果を処理結果記憶装置 5に一括して格納 d5する。
[0049] このようにして、電文種別毎に設けられた各々の電文処理部は、該電文処理要求 を受けて、該入力電文記憶装置に格納されてレ、る未処理の電文を一括して読み出 すと共に、該管理情報記憶装置から各電文の処理に必要な情報を参照'更新して、 各電文を処理し、それらの処理結果を処理結果記憶装置に一括して格納し、更に該 入力電文記憶装置中の対応する電文を、処理済として更新する。
[0050] 従って、電文受付部 A1はクライアントからの状況確認要求や結果取得要求に応じ て、入力電文記憶装置 4と処理結果記憶装置 5から読み出して要求元のクライアント に応答できる。
[0051] 上記のように、本発明に係る電文処理装置は、処理対象の大量の電文に一括して アクセスするので、アクセス競合は、その集約された単位内では無くなり、一件毎にァ クセスする従来例に比べて極めて少なくなる。
[0052] また、第 1階層の電文受付部 A1で電文データを一括保存し、最終階層である第 4階 層の電文種別毎処理部へは、三次集約した電文処理要求のみを転送し、途中、第 2 、第 3階層での電文データの転送処理が必要ないので、電文の処理効率を更に向上 させること力 Sできる。
[0053] また、電文種別毎に集約した電文処理要求を受けることは必須ではなぐ対応する 電文処理部の機能に合わせて、処理内容毎に段階的に集約した電文処理要求を受 ける構成としてもその効果が変わるものではない。
[0054] (8)上記（7)における電文処理装置の電文受付部は、各クライアントから電文種別 毎の結果取得要求を受けた時、該処理結果記憶装置から処理結果を読み出して該 クライアントに応答することができる。
[0055] これを、再び図 2及び図 3を参照して以下に説明する
[0056] まず、クライアント 1からのポーリングなどにより、先の新規受付応答 cl_2で通知した 通番を含む状況確認要求 cl_3が送られて来ると、電文受付部 A1は処理状況取得 al_5を実行して、入力電文記憶装置 4からその通番に対応する処理状態データの電 文処理状態取得 dl_2を行う。次に、電文受付部 A1は、その取得した処理状態を基に 処理状況応答 al_6を実行して、状況確認要求 cl_3があったクライアント 1に対して状 況確認応答 cl_4を返す。
[0057] また、クライアント 1から、先に通知した通番を含む結果取得要求 cl_5が送られて来 ると、電文受付部 Alは処理結果取得 al_7を実行し、処理結果記憶装置 5からその通 番に対応する電文の電文処理結果取得 d2を行う。次に、電文受付部 A1は処理結果 応答 al_8を実行して、その取得した電文の処理結果を基に結果取得要求 cl_5があつ たクライアント 1に対して結果取得応答 cl_6を返す。
[0058] このようにして、新規要求 cl_lから始まり結果取得応答 cl_6で終わる一つのトランザ クシヨンは、新規要求 cl_lの電文処理要求が一次集約されて電文処理要求部 A2に 通知され、最終的には電文種別毎処理装置 3の電文処理部で処理されるが、残る状 況確認要求 cし 3 (上記 (4)参照。 )と結果取得要求 cし 5の電文処理要求については、 電文受付部 A1が上記のようにして状況確認応答 cl_4と結果取得応答 cl_6の応答を することで完結する。
[0059] 従って、新規要求 cl_lとその後の状況確認要求 cl_3及び結果取得要求 cl_5、すな わち、電文処理の内容によって、その処理を該電文受付部 A1と該電文処理部 A4に 局在化させることにより、電文受付部 A1が処理する電文については、電文処理部 A4 がアクセスする必要が無くなるので、その処理に係るデータへのアクセス競合を更に 低減すること力 Sできる。
発明の効果
[0060] 本発明に係る電文処理装置は、各受付部が同時多発する大量の電文処理要求を 受け付けて、それらの電文を入力電文記憶装置に格納すると共に、その電文処理要 求を集約して各電文処理部へ通知し、各電文処理部が、その集約された電文処理 要求を受けて、未処理電文を入力電文記憶装置から一括して読み出して処理する ので、電文処理件数当たりのファイルやデータベースへのアクセス回数が極少化さ れ、アクセス効率が向上するという利点がある。
[0061] また、受けた各電文処理部は、各受付部が入力電文記憶装置に格納した電文を、 その電文処理要求に基づいて、処理対象となる電文をその同じ入力電文記憶装置 力 一括して読み出して処理するので、その電文処理要求を段階的に集約する過程 におレ、ては、それらの電文データ転送処理が不要となる利点がある。
[0062] 更に、該電文受付部は、該クライアントから新規に要求された電文処理要求に通番 を付加して該入力電文記憶装置に一括で書き込みを行うと共に、要求元のクライァ ントには該通番を通知するので、その通番をキーとしてその後の電文処理を進めるこ とにより、クライアント側の要求内容と電文処理装置側の処理内容との同期処理が可 能となる利点がある。
[0063] また、各クライアントから新規に要求された電文処理要求を電文処理部が処理し、 それに続く同じ通番を含む電文処理要求を電文受付部が処理することにより、電文 受付部が処理する電文については、電文処理部がアクセスする必要がないので、そ の処理に係るデータへのアクセス競合を更に低減可能となる利点がある。
[0064] また、該電文処理要求部及び該電文処理要求受付部は、各々が前階層で集約さ れた電文処理要求を受けて、それぞれに予め定められた時間まで待受処理を行うこ とにより該二次集約又は三次集約を行うので、段階的に集約規模を拡大することが 容易であるという利点がある。
[0065] また、該電文処理部は、管理情報記憶装置から各電文の処理に必要な情報を参 照'更新をして、各電文データを処理し、それらの処理結果を処理結果記憶装置に 一括して格納し、更に入力電文記憶装置の対応する電文を、処理済として更新する ので、電文受付部はクライアントからの状況確認要求や結果取得要求に応じて、入 力電文記憶装置と処理結果記憶装置から読み出して要求元のクライアントに応答で きるという利点がある。
発明を実施するための最良の形態
[0066] 下、 S月に係る の ¾ 、チゲットチ^ 1システム 例に って 、 5— 10» 照して 用する
[0067] まず、 ffiはそのシステム全体の構成例を示しており、その構成は、電文種別毎処 理装置 3の予約受付処理装置 3_1と空席照処理装置 3_2を除いて、既に説明した図 1 のシステム構成と同様である。すなわち、図 1の電文種別 1処理装置 3_1及び電文種 別 2処理装置 3_2が、図 5では予約受付処理装置 3_1及び空席照会処理装置 3_2へと 、それぞれ電文種別の具体的な例として名称が変更されている以外は同様であり、 図 5のシステム構成の説明は省略する。
[0068] 次に、図 1一図 3及び図 5に示した電文受付部 A1の実施例を、図 6及び図 7に分割 して示された処理フローブロック図を参照して以下に説明する まず、図 6に示す複 数のクライアント 1からの電文種別毎の電文処理要求である予約受付要求と空席照 会要求に対する、受付からその応答までの処理フローを説明する。
[0069] 図 6において、クライアント 1_11、 1_12及び 1_13より同時に発生した各々の予約受付 要求 cl_l及び空席照会要求 cl_3は、それぞれの電文と共に、それぞれに対応するク ライアント応答スレッド al_lによって同時並行して受信され、各要求とその電文に通番 を付加するための通番採番 al_l lの処理が施こされる。
[0070] 通番が付加された各電文は、一時格納 al_12によって電文種別毎に予約受付電文 一時保存領域 10_1と空席照会電文一時保存領域 10_2 (以下、「電文種別毎一時保 存領域 10丄 10_2」と呼ぶ場合がある。）にそれぞれ一時保存される。
[0071] その後、各クライアント応答スレッド al_lは待受起動 al_13に移り、電文種別毎に予 約受付待受スレッド al_2、又は空席照会待受スレッド al_3に制御を渡すと共に、完了 待合 al_14に移り、予約受付待受スレッド al_2、又は空席照会待受スレッド al_3から電 文処理要求の送信完了を受けるまで待合わせ状態に入る。
[0072] 一方、待受起動 al_13で起動された予約受付待受スレッド al_2、及び空席照会待受 スレッド al_3では、対応する電文種別毎一時保存領域 10丄 10_2の保存件数をそれ ぞれの件数チェック al_21、 al_31しており、その結果を一時待受 al_22、 al_32に渡す。 各一時待受 al_22、 al_32では、その件数が予め定めた件数に達した時、及び予め定 めた待受時間を超過した時の何れか早いタイミングで、電文書込 al_23、 al_33にその タイミングを通知する。この通知を受けて、各電文書込 al_23、 al_33は対応する電文 種別毎一時保存領域 10_1、 10_2にそれまで保存されていた電文を、一括して入力電 文記憶装置 4に書き込み（アクセス dl_w)、その後、対応する電文処理要求送信 al_24 、 al_34に処理を移す。
[0073] 各電文処理要求送信 al_24、 al_34では、処理対象の電文があることを、予約受付 電文処理要求 c2_l、空席照会電文処理要求 c2_2として、対応する電文処理要求部 A2へ送って通知すると共に、完了待合 al_14状態にあるクライアント応答スレッド al_l に電文処理要求送信 al_24、 al_34の完了を知らせる。
[0074] その電文処理要求送信 al_24、 al_34の完了を受けて、クライアント応答スレッド al_l は完了待合 al_14状態から受付応答 al_15に移り、クライアント 1_11及び 1_12に対して は予約受付応答 cl_2を、クライアント 1_13に対しては空席照会応答 cl_4を、それぞれ 、対応する通番と共に返す。
[0075] このように、第 1階層の電文受付部 A1は、複数のクライアントから同時多発する大量 の電文処理要求を、予め定めた件数、又は予め定めた時間内に受け付けた電文デ ータを電文種別毎に設けられた一時保存領域 10丄 10_2に通番を付けて一旦保持し 、それらを一括して入力電文記憶装置 4に格納（アクセス dl_w)すると共に、電文種別 毎に一次集約した電文処理要求（予約受付電文処理要求 C2_l、空席照会電文処理 要求 c2_2)を、対応する第 2階層の電文処理要求部 A2に通知する。
[0076] また、電文受付部 A1は、それらの通番を対応するそれぞれのクライアント 1へ応答 cl_2、 cl_4して通知する。そして、それらの通番は一つのトランザクションが完了する まで、すなわち、その通番を取得したクライアント 1が、次に説明する電文の処理状況 確認や処理結果を取得して完了するまで使用される。
[0077] このようにして、電文受付部 A1は、各クライアントから新規に要求された電文処理要 求を電文と共にその種別毎に通番を付加する通番処理と、予め定めた件数又は予 め定めた時間になるまで該電文を待受ける待受処理とで一旦保存し、一定件数又は 一定時間に達した時、それまで保存した電文を該通番と共に該入力電文記憶装置 に一括で書き込みを行い、要求元のクライアントには該通番を返す。
[0078] 従って、各クライアント 1が、既に電文処理要求が受け付けられた後の状況確認や 結果取得を要求する場合は、新規受付応答 cl_2で取得した通番を用いて行い、電 文処理装置側はそれと同じ通番をキーとして電文処理を進めることにより、クライアン ト側の要求内容と電文処理装置側の処理内容との同期処理が可能となる。
[0079] 次に、図 7を参照して、複数のクライアント 1から既に要求された電文の処理状況の 確認要求を同時並行して受けた時の、受付からその応答までの処理フローを説明す る。
[0080] 各クライアント 1_11、 U3が取得した通番を用いて予約状態確認 cl_5、照会状態確 認 cl_9を各々が行うと、各クライアント応答スレッド al_lが、状態読出 al_16を実行して 入力電文記憶装置 4からその通番に対応する処理状態を読み出し (アクセス dl_r)、 次に状態応答 al_17を実行する。 [0081] 各状態応答 al_17では、予約状態確認 cl_5があったクライアント 1_11には予約状態 応答 cl_6、照会状態確認 cl_9があったクライアント 1_13には照会状態応答 cl_10でそ れぞれに応答し、処理経過を知らせる。
[0082] 既に処理が完了している応答を受けたクライアント 1_11、 1_13は、引き続きその通番 を用いて予約結果取得 cl_7や照会結果取得 cl_l lをそれぞれ要求することができる。
[0083] 各クライアント応答スレッド al_lは、クライアント 1_11、 1_13から予約結果取得 cl_7、照 会結果取得 cl_l lを受け取ると、それぞれが結果読出 al_18を実行して処理結果記憶 装置 5からその通番に対応する予約処理結果を読み出し (アクセス d2_r)、次に結果 応答 al_19を実行する。
[0084] 各結果応答 al_19では、対応するクライアント 1_11、 U3に予約結果応答 cl_8や照会 結果応答 cl_12で応答し、それぞれの結果を返す。
[0085] このようにして、各クライアント 1が、新たな電文処理を要求 (新規トランザクション発 生）した時に電文受付部 A1からの新規受付応答 cl_2で通番を取得し、その後の電文 処理状況の問い合わせや結果取得などを要求する場合は、その通番を用いて行う。 電文処理装置側はそれと同じ通番をキーとして電文処理を進めることにより、クライア ント側の要求内容と電文処理装置側の処理内容との同期を保ちながら、一つの処理 が終了するまで、その通番を用いて処理する。
[0086] また、上記のように、電文受付部 A1は、予約受付要求 cl_l及び空席照会要求 cl_3 を電文種別毎に一次集約して次の階層に通知すると共に、その他の予約状態確認 cl_5、予約結果取得 cl_7や照会状態確認 cl_9、照会結果取得 cU lについては、電 文受付部 A1が、入力電文記憶装置 4や処理結果記憶装置 5からその通番に対応す る処理状態又は結果を読み出して応答する。
[0087] 次に、図 1一図 3及び図 5に示した電文処理要求部 A2の実施例を、図 8に示した処 理フローブロック図を参照して説明する
[0088] まず、電文処理要求部 A2の受付スレッド a2_lは、電文受付部 A1からの予約受付電 文処理要求 c2_10を受けると、予約受付電文が発生したことを示す発生フラグを発生 フラグ設定 a2_l lが予約受付電文発生フラグ 20_1に設定する。但し、発生フラグ設定 a2_l lは、予約受付待受スレッド a2_2の多重起動を避けるために、発生フラグを設定 する前にその発生フラグが OFF状態であることを確認した上で ON状態に設定 (セット )すると共に待受起動 a2_12に移行する。
[0089] 従って、待受起動 a2_12は、発生フラグが OFF状態から ON状態に設定された時の み、予約受付待受スレッド a2_2の起動を行う。なお、発生フラグが ON状態であった場 合は、予約受付待受スレッド a2_2が既に起動されているので、起動しない。
[0090] 受付スレッド a2_3は、予約受付電文発生フラグ 20_1が ON状態の時に予約受付電文 処理要求 c2_l lを受けた場合を示しており、受付スレッド a2_3の発生フラグ設定 a2_l l は実行せず、且つ予約受付待受スレッド a2_2も起動しないので、待受起動 a2_12から 予約受付待受スレッド a2_2への矢印付き実線は示されてレ、なレ、。
[0091] 一方、起動された予約受付待受スレッド a2_2は、一時待受 a2_13を行い、予め定めら れた時間まで待受けてその時間が経過すると、電文処理要求送信 a2_14に移行する
[0092] 電文処理要求送信 a2_14は、予約受付処理装置 3_1の電文処理要求受付部 A3_l ( 図 5参照）へ処理対象の電文があることを通知し (イベント c3_l)、次にフラグ解除 a2_15を起動する。フラグ解除 a2_15は、予約受付電文発生フラグ 20_1の発生フラグを 解除 (OFF)状態にする。
[0093] 次に、受付スレッド a2_4が、空席照会電文処理要求 c2_20を受けると、空席照会電文 が発生したことを示す発生フラグを発生フラグ設定 a2_l lが空席照会電文発生フラグ 20_2に設定する。但し、発生フラグ設定 a2_l lは、空席照会待受スレッド a2_5の多重起 動を避けるために、上記の予約受付待受スレッド a2_2起動時と同様に、発生フラグを 設定する前にその発生フラグが OFF状態であることを確認した上で ON状態に設定す ると共に待受起動 a2_12に移行する。
[0094] 受付スレッド a2_6は、空席照会電文発生フラグ 20_2が ON状態の時に空席照会電文 処理要求 c2_21を受けた場合を示しており、受付スレッド a2_6の発生フラグ設定 a2_l l は実行せず、且つ空席照会待受スレッド a2_5も起動しないので、待受起動 a2_12から 予約受付待受スレッド a2_2への矢印付き実線は示されてレ、なレ、。
[0095] 一方、起動された空席照会待受スレッド a2_5は、一時待受 a2_13を行い、予め定めら れた時間まで待受けてその時間が経過すると、電文処理要求送信 a2_14に移行する [0096] 電文処理要求送信 a2_14は、空席照会処理装置 3_2の電文処理要求受付部 A3_2 ( 図 5参照）へ処理対象の電文があることを通知し (イベント c3_2)、次にフラグ解除 a2_15を起動する。フラグ解除 a2_15は、予約受付電文発生フラグ 20_2の発生フラグを 解除 (OFF)状態にする。
[0097] このように、電文処理要求部 A2は、各電文受付部 A1が電文種別毎に一次集約した 電文処理要求 (イベント c2)を、例えば予め定めた待受け時間（例えば 0.5秒）を持つ ことにより更に集約（二次集約）して、電文種別毎に対応した電文処理要求受付部 A3 に電文処理要求 (イベント c3)として通知する。
[0098] 次に、図 1及び図 3— 5に示した電文処理要求受付部 A3 1、 A3 2の実施例を図 9に 示した処理フローブロック図を参照して説明する なお、本実施例では電文種別毎 処理装置 3に属するものとして、図 5のシステム構成例に示したように、予約受付処理 装置 3_1と空席照会処理装置 3_2の二つを挙げており、電文処理要求受付部 A3_lと A3_2はそれぞれに対応して設けられてレ、る。
[0099] まず、予約受付の電文処理要求を受け付ける処理フローから説明する。
[0100] 電文処理要求受付部 A3_lの受付スレッド a3_lは、電文処理要求部 A2からの電文処 理要求 c3_10を受けると、電文の処理要求が発生したことを示す発生フラグを、発生フ ラグ設定 a3_l lにより予約受付処理発生フラグ 30_1に設定すると共に、待受起動 a3_12 する。但し、発生フラグ設定 a3_l lは、予約受付待受スレッド a3_2の多重起動を避ける ために、その発生フラグが OFF状態である場合に限り ON状態に設定すると共に待受 起動 a3_12に移行する。
[0101] 従って、待受起動 a3_12は、発生フラグが OFF状態から ON状態に設定された時の み、予約受付処理待受スレッド a3_2の起動を行う。なお、予約受付処理発生フラグ 30_1が ON状態の場合は、予約受付処理待受スレッド a3_2が既に起動されているので 、更に起動することはしない。
[0102] 受付スレッド a3_3は、予約受付処理発生フラグ 30_1が ON状態の時、電文処理要求 c3_llを受けた場合を示しており、この場合は予約受付処理待受スレッド a3_2を起動し なレヽとレ、う意味で、待受起動 a3_12から予約受付処理待受スレッド a3_2への矢印付き 実線が除去されている。
[0103] 起動された予約受付処理待受スレッド a3_2は、一時待受 a3_13を行い、例えば予め 定められた時間まで待受けてその時間が経過すると、電文処理要求送信 a3_14に移 行する。
[0104] 電文処理要求送信 a3_14は、予約受付処理装置 3_1の電文処理部 A4_l (図 5参照） へ処理対象の電文があることを通知（イベント c4_l)すると、次にフラグ解除 a3_15を起 動する。フラグ解除 a3_15は、予約受付電文発生フラグ 30_1の予約受付処理発生フラ グを解除して OFF状態にする。
[0105] 次に、電文処理要求受付部 A3_2において、空席照会の電文処理要求を受け付け る処理フローは上記の予約受付の電文処理要求を受けた場合 (電文処理要求受付 部 A3_l)と一部を除き同様である。
[0106] すなわち、受付スレッド a3_4の発生フラグ設定 a3_ll処理力 S、空席照会電文が発生 したことを示す発生フラグを空席照会処理発生フラグ 30_2に設定することと、空席照 会処理待受スレッド a3_5が空席照会の電文処理部 A4_2 (図 5参照）へ処理対象の電 文があることを通知（イベント c4_2)することを除き、上記の予約受付の電文処理要求 を受け付ける処理と同様の処理フローとなる。また、受付スレッド a3_6が、空席照会処 理発生フラグ 30_2が ON状態の時に電文処理要求 c3_21を受けたため、空席照会処 理待受スレッド a3_5を起動しなレ、ことを示してレ、る点も同様である。
[0107] このようにして、図 8及び図 9にそれぞれ示した電文処理要求部 A2及び電文処理要 求受付部 A3は、それぞれ、該電文処理要求を受けると、対応する電文処理要求が 発生したことを示す電文発生フラグ、及び電文の処理要求が発生したことを示す処 理発生フラグが OFF状態であることを各々が確認した上で該電文発生フラグ、及び 該処理発生フラグを〇N状態に設定し予め定められた時間まで待受処理を行い、各 々が集約した電文処理要求をそれぞれ該電文処理要求受付部及び該電文処理部 へ送って処理対象の電文が発生したことを通知すると共に、両フラグを OFF状態に 戻す。
[0108] 従って、各々の待受処理の多重起動を避けることができ、更に多くのクライアントや イベント数の増加に容易に対応できると共に、処理件数当たりのファイルやデータべ ースへのアクセス回数は更に少なくなり、アクセス効率が向上する。
[0109] 次に、図 1及び 5に示した各電文処理部 A4 1、 A4 2の実施例を図 10に示した処理 フローブロック図を参照して説明する。なお、本実施例では電文種別毎処理装置 3に 属するものとして、図 5のシステム構成例に示したように、予約受付処理装置 3_1と空 席照会処理装置 3_2の二つを挙げており、電文処理部 A4_lは予約受付の電文処理 部、電文処理部 A4_2は空席照会の電文処理部にそれぞれ対応している。
[0110] まず、電文処理部 A4_lは、電文処理要求受付部 A3_lから状況確認要求や結果取 得要求などの処理要求 c4_lを受けると、未処理予約受付電文一括読出 a4_l lを行い 、入力電文記憶装置 4から未処理の予約受付電文を一括して読み出す（アクセス d3_r )。なお、その電文が処理済であるか否かは、各電文処理部 A4が電文処理後に入力 電文記憶装置 4の処理状態を更新するなどによって知ることができる。
[0111] 続いて、電文処理部 A4_lは、予約情報読出 a4_12で管理情報記憶装置 6の予約情 報を参照し（アクセス d4_r)、予約結果登録 a4_13でそれを更新（アクセス d4_w)して電 文の処理を行う。次に、その処理結果を電文処理結果登録 a4_14で処理結果記憶装 置 5に格納（アクセス d5_w)し、次の電文処理状態更新 a4_15で入力電文記憶装置 4の 対応する処理状態を更新（アクセス d3_w)して一連の処理フローを終了する。
[0112] 次に、電文処理部 A4_2が、電文処理要求受付部 A3_2から処理要求 c4_2を受けると 、未処理空席照会電文一括読出 a4_21を実行して入力電文記憶装置 4から未処理の 空席照会電文を一括して読み出す（アクセス d3_r)。続いて、空席情報読出 a4_22で 管理情報記憶装置 6の空席情報を参照（アクセス d4_r)し、その処理結果を電文処理 結果登録 a4_23で処理結果記憶装置 5に格納（アクセス d5_w)する。次に電文処理状 態更新 a4_24で入力電文記憶装置 4の対応する処理状態を更新（アクセス d3_w)して 一連の処理を終了する。
[0113] このようにして、電文処理部 A4は、段階的に集約された電文処理要求を受けて、入 力電文記憶装置 4に格納されている未処理の電文を一括して読み出すと共に、管理 情報記憶装置 6から各電文の処理に必要な情報を参照 ·更新して、各電文データを 処理し、それらの処理結果を処理結果記憶装置 5に一括して格納し、更に入力電文 記憶装置 4の対応する電文を、処理済として更新する。 [0114] 従って、電文受付部 Alはクライアントからの状況確認要求や結果取得要求に応じ て、入力電文記憶装置 4と処理結果記憶装置 5から一括して読み出して要求元のクラ イアントに応答できる。
[0115] 以上のように、本発明に係る電文処理装置は、複数のクライアントから同時多発す る大量の電文を集約して処理するので、ファイルやデータベースへのアクセス回数が 極少化され、アクセス効率が向上し、電文を効率的に処理することができる。
[0116] 従って、その並列処理によるデータ参照.更新のためのアクセス競合がボトノレネック とはならず、その多重分散処理の効果が容易に得られる。
[0117] また、そのアクセス競合を回避するための参照 ·更新を行うファイルやデータベース の複製を多数設ける必要がないので、それらを自動的に同期化させるような複雑な システム構成を採ることなぐ経済的にスケーラビリティを確保した電文処理装置を実 現すること力 Sできる。
[0118] また、実施例のように電文種別毎に集約することは必須ではなぐ対応する電文処 理部の例えば処理機能別毎 ·処理内容別毎に段階的に集約してもその効果に変わ りはない。
[0119] また、段階的に電文処理要求を集約することは、三次集約に限定されず、電文処 理装置の要件に合わせて任意に集約規模を拡大縮小することでコストパフオーマン スを最適化することも可能である。
[0120] また、本発明に係る電文処理装置は、本実施例で示したチケット予約システムのみ ならず、 WEBや金融'流通のオンライン処理、大規模ネットワークのオペレーションシ ステム等、多数のクライアントから同時に発生する処理要求やイベント通知等の電文 をリアルタイムに処理する電文処理システムに適用できる。
図面の簡単な説明
[0121] [図 1]本発明に係る電文処理装置の原理 (システム構成）を示すブロック図である。
[図 2]本発明に係る電文処理装置の原理 (電文受付部）を示すブロック図である。
[図 3]本発明に係る電文処理装置の原理 (電文処理要求部/電文処理要求受付部） を示すブロック図である。
[図 4]本発明に係る電文処理装置の原理（電文処理部）を示すブロック図である。 [図 5]本発明に係る電文処理装置の実施例（チケット予約システム構成）を示すブロッ ク図である。
[図 6]本発明に係る電文処理装置の実施例（電文受付部の 1/2)を示すブロック図で ある。
[図 7]本発明に係る電文処理装置の実施例（電文受付部の 2/2)を示すブロック図で ある。
[図 8]本発明に係る電文処理装置の実施例（電文処理要求部）を示すブロック図であ る。
[図 9]本発明に係る電文処理装置の実施例（電文処理要求受付部）を示すブロック図 である。
[図 10]本発明に係る電文処理装置の実施例（電文処理部）を示すブロック図である。 符号の説明
1、 1_11一 1_η3 クライアント
2、 2_1、2_2 クライアント接続装置
3 電文種別毎処理装置
3_1 電文種別 1処理装置、予約受付処理装置
3_2 電文種別 2処理装置、空席照会処理装置
4 入力電文記憶装置
5 処理結果記憶装置
6 管理情報記憶装置
10_1 予約受付電文一次保存領域
10_2 空席照会電文一次保存領域
20_1 予約受付電文発生フラグ
20_2 空席照会電文発生フラグ
30_1 予約受付処理発生フラグ
30_2 空席照会処理発生フラグ
Α1、Α1_1— Al_n 電文受付部
A2電文処理要求部 A3、A3_1、A3_2 電文処理要求受付部
A4_1、A4_2 電文処理部
al_l クライアント応答スレッド
al_2、 a2_2 予約受付待受スレッド
al_3、 a2_5 空席照会待受スレッド
a2_U a2一 3、 a2_4、 a2一 6、 a3_l、 a3一 3、 a3_4、 a3一 6 受付スレッド a3_2 予約受付処理待受スレッド
a3_5 空席照会処理待受スレッド
a4_l l 未処理予約受付電文一括読出
a4_12、a4_22 予約情報読出
a4_13、予約結果登録
a4_14, a4_23 電文処理結果登録
a4_15、 a4_24 電文処理状態更新
a4_21 未処理空席照会受付電文一括読出
cl、 c2、 c3、 c4 イベントし 1、 _2などを付加した符号もある。 ) dl、 d2、 d3、 d4、 d5 アクセスし 1、 _2、— r、 _wを付加した符号もある。 ) 図中、同一符号は同一又は相当部分を示す。

Claims

請求の範囲
[1] 複数のクライアントから同時に電文及びその電文処理要求を受け付けて該電文処 理要求を集約すると共に、該電文処理要求に係る電文を、入力電文記憶装置に一 括格納する第 1手段と、
該第 1手段で集約した電文処理要求を受けて更に一回以上集約すると共に、該集 約した電文処理要求に基づき該電文処理要求に対応した電文を、該入力電文記憶 装置から一括して読み出して対応した処理を行う第 2手段と
を備え、
クライアントからの電文処理要求を受付けた時に通知した通番により、クライアントか ら電文処理状態や電文処理結果を随時、照会可能としたことを特徴とした電文処理 装置。
[2] 複数のクライアントから同時に電文処理要求を受け付けて該電文処理要求を電文 種別毎に一次集約すると共に該電文処理要求に係る電文を入力電文記憶装置に電 文種別毎に一括格納する複数の電文受付部、及び該一次集約した電文処理要求を 受けて、該電文種別毎に更に二次集約する電文処理要求部を、各々が含む複数の クライアント接続装置と、
該電文処理要求に基づき各クライアント接続装置で生成された電文処理要求を受 けて、それらを更に該電文種別毎に三次集約する電文処理要求受付部、及び該電 文処理要求受付部から該三次集約した電文処理要求を受けて、該電文処理要求に 対応した電文データを、該入力電文記憶装置から一括して読み出し該電文種別に 対応した処理を行う電文処理部を、各々が含む複数の電文種別毎処理装置と、 を備えたことを特徴とした電文処理装置。
[3] 請求の範囲 2において、
該電文受付部が、該クライアントから新規に要求された電文及びその電文処理要 求に通番を付加する通番処理と、予め定めた件数又は予め定めた時間になるまで 該電文を一旦保存し、該件数又は該時間に達した時、それまで保存した電文を該通 番と共に該入力電文記憶装置に一括して書き込み、要求元のクライアントには該通 番を通知することを特徴とした電文処理装置。
[4] 請求の範囲 3において、
該電文受付部が、各クライアントから該通番を用いた電文種別毎の確認要求を受 けた時、該入力電文記憶装置から該通番に対応する電文処理状態を読み出して該 クライアントに応答することを特徴とした電文処理装置。
[5] 請求の範囲 2において、
該電文処理要求部及び該電文処理要求受付部が、それぞれ、該電文処理要求を 受けて、それぞれに予め定められた時間まで待受処理を行うことにより各集約を行い 、各々が集約した電文処理要求をそれぞれ該電文処理要求受付部及び該電文処 理部へ送って処理対象の電文が発生したことを通知することを特徴とした電文処理 装置。
[6] 請求の範囲 5において、
該電文処理要求部及び該電文処理要求受付部が、それぞれ、該電文処理要求を 受けると、対応する電文処理要求が発生したことを示す電文発生フラグ、及び電文の 処理要求が発生したことを示す処理発生フラグが OFF状態であることを各々が確認 したときのみ該電文発生フラグ、及び該処理発生フラグを ON状態に設定し予め定め られた時間まで該待受処理を行い、各々が集約した電文処理要求をそれぞれ該電 文処理要求受付部及び該電文処理部へ送って処理対象の電文が発生したことを通 知すると共に、両フラグを OFF状態に戻すことを特徴とした電文処理装置。
[7] 請求の範囲 4において、
該電文処理部が、該電文処理要求を受けて、該入力電文記憶装置に格納されて いる未処理の電文を一括して読み出すと共に、管理情報記憶装置から各電文の処 理に必要な情報を参照 ·更新をして、各電文を処理し、それらの処理結果を処理結 果記憶装置に一括して格納し、更に該入力電文記憶装置中の対応する電文を、処 理済として更新することを特徴とした電文処理装置。
[8] 請求の範囲 7において、
該電文受付部が、各クライアントから電文種別毎の結果取得要求を受けた時、該処 理結果記憶装置から処理結果を読み出して該クライアントに応答することを特徴とし た電文処理装置。
PCT/JP2005/001014 2005-01-26 2005-01-26 電文処理装置 Ceased WO2006080058A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2005/001014 WO2006080058A1 (ja) 2005-01-26 2005-01-26 電文処理装置
JP2007500371A JPWO2006080058A1 (ja) 2005-01-26 2005-01-26 電文処理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2005/001014 WO2006080058A1 (ja) 2005-01-26 2005-01-26 電文処理装置

Publications (1)

Publication Number Publication Date
WO2006080058A1 true WO2006080058A1 (ja) 2006-08-03

Family

ID=36740093

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/001014 Ceased WO2006080058A1 (ja) 2005-01-26 2005-01-26 電文処理装置

Country Status (2)

Country Link
JP (1) JPWO2006080058A1 (ja)
WO (1) WO2006080058A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013174973A (ja) * 2012-02-23 2013-09-05 Fujitsu Ltd イベント処理方法、イベント収集方法、イベント処理プログラム、イベント収集プログラム及び情報処理装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6394360A (ja) * 1986-10-09 1988-04-25 Hitachi Ltd トランザクション処理方法
JPH01291356A (ja) * 1988-05-18 1989-11-22 Nec Corp メッセージデータのバッチ入力によるオンライントランザクション処理方式
JPH03105544A (ja) * 1989-09-20 1991-05-02 Hitachi Ltd オンライントランザクション処理システム
JPH0973432A (ja) * 1995-09-08 1997-03-18 Hitachi Ltd オンライントランザクション高速処理方式

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6394360A (ja) * 1986-10-09 1988-04-25 Hitachi Ltd トランザクション処理方法
JPH01291356A (ja) * 1988-05-18 1989-11-22 Nec Corp メッセージデータのバッチ入力によるオンライントランザクション処理方式
JPH03105544A (ja) * 1989-09-20 1991-05-02 Hitachi Ltd オンライントランザクション処理システム
JPH0973432A (ja) * 1995-09-08 1997-03-18 Hitachi Ltd オンライントランザクション高速処理方式

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013174973A (ja) * 2012-02-23 2013-09-05 Fujitsu Ltd イベント処理方法、イベント収集方法、イベント処理プログラム、イベント収集プログラム及び情報処理装置

Also Published As

Publication number Publication date
JPWO2006080058A1 (ja) 2008-06-19

Similar Documents

Publication Publication Date Title
CN101706811B (zh) 一种分布式数据库系统事务提交方法
JP5714571B2 (ja) キャッシュクラスタを構成可能モードで用いるキャッシュデータ処理
KR101623663B1 (ko) 클라이언트/서버 시스템에서 분산된 복제 콘텐츠들의 강한 일관성을 유지하는 방법 및 시스템
CN112860393B (zh) 一种分布式任务调度方法及系统
CN101188566B (zh) 一种集群环境下数据缓存同步的方法及系统
CN101853186A (zh) 分布式事务恢复系统和方法
CN113626184B (zh) 一种超融合性能优化方法、装置及设备
EP4276651A1 (en) Log execution method and apparatus, and computer device and storage medium
CN102591741A (zh) 使用可缩放虚拟容量实现灾难恢复的方法和系统
CN101383839A (zh) 基于数据服务器的数据分发系统及其实现方法
CN111597270A (zh) 数据同步方法、装置、设备及计算机存储介质
WO2023082992A1 (zh) 数据处理方法以及系统
US20090133036A1 (en) Coordinating resources using a volatile network intermediary
CN101977164B (zh) 一种SaaS模式下的数据交互方法及系统
CN116382943A (zh) 顺序消息处理方法、总线系统、计算机设备及存储介质
JP5331050B2 (ja) データ同期システム、データ同期方法、情報処理装置、情報処理方法、およびプログラム
CN113190624B (zh) 基于分布式跨容器的异步转同步调用方法及装置
WO2006080058A1 (ja) 電文処理装置
WO2006131440A1 (en) Apparatus, system, and method for facilitating communication between an enterprise information system and a client
CN117056303B (zh) 适用于军事行动大数据的数据存储方法及装置
CN115048061B (zh) 基于Raft的冷数据存储方法
CN118796363A (zh) 一种分布式事务管理方法、装置、电子设备和计算机程序产品
JP2003018165A (ja) ネットワーク情報通知方法
Faiz et al. Database replica management strategies in multidatabase systems with mobile hosts
CN112069160B (zh) 一种基于cap数据清洗同步方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2007500371

Country of ref document: JP

122 Ep: pct application non-entry in european phase

Ref document number: 05709354

Country of ref document: EP

Kind code of ref document: A1

WWW Wipo information: withdrawn in national office

Ref document number: 5709354

Country of ref document: EP