JP2003345610A - Transaction processing apparatus, transaction processing method for the apparatus, transaction processing program and computer-readable recording medium where the program is recorded - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a transaction processing apparatus capable of efficiently canceling transactions of a plurality of different scenarios which are called by the same scenario by branching and processed in parallel. <P>SOLUTION: The transaction processing apparatus when acquiring execution histories for each process in transaction execution defines canceling processes for each of their history elements. When the canceling processes are executed in the reverse order of the histories, the canceling processes are actuated on conditions that they are made to correspond to the history elements, thereby efficiently canceling the plurality of processes which are executed in parallel together at a time (canceling processes S<SB>11</SB>, S<SB>12</SB>, and S<SB>13</SB>by a canceling process S<SB>1</SB>', processes S<SB>21</SB>, S<SB>22</SB>, and S<SB>23</SB>by a canceling process S<SB>2</SB>', and processes S<SB>31</SB>and S<SB>32</SB>by a canceling process S<SB>3</SB>' together at a time in parallel). <P>COPYRIGHT: (C)2004,JPO

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a transaction processing apparatus for processing a transaction composed of a series of plural processes according to a scenario describing a processing procedure, a transaction processing method of the apparatus, a transaction processing program, and a program. The present invention relates to a recorded computer-readable recording medium, and more particularly to a transaction processing apparatus and a transaction processing apparatus capable of efficiently canceling a plurality of different scenarios of transactions that are called and branched from the same scenario and processed in parallel. Transaction processing method, a transaction processing program, and a computer-readable recording medium recording the program.

[0002]

2. Description of the Related Art In order to enable execution of processing by a plurality of computers, first, a scenario description language is used.
Describe how computers cooperate, the order in which each computer performs processing, input information for each computer's processing, output information that is the result of each computer's processing, etc., in files called scenarios and documents stored in databases. . Then, based on this scenario, an execution management computer called a scenario engine controls each computer.

[0003] A transaction is a series of processes executed by a computer, and is used to guarantee that when an attempt to execute a process fails, the state is the same as before the process was executed. For example, SAGA is a transaction guarantee technology in the case of including so-called asynchronous processing such as asynchronous communication with another device.
(Introduction to Transaction Processing Technology (by Philip A. Bernstein and Eric Newcomer, Nikkei BP, ISBN 4-8222-28026-)
8)).

The SAGA manages the execution history information of each process constituting a transaction as a list. When a failure occurs, the execution history information list is traced in the reverse order of the execution order, and the compensation process for canceling each process is sequentially executed.

Here, consider a case where parallel execution processing is executed according to a scenario as shown in FIG. in this case,
The execution is performed in parallel for each path branched in FIG. 8A, and the execution history is held as shown in FIG. If a failure occurs during the execution of the processing shown in FIG. 8A, the elements of this execution history are traced in reverse order, and the cancellation processing is executed one by one in the order of FIG. 8B.

That is, in the SAGA technology, in the case of failure recovery processing of transactions executed in parallel by branching, at the time of child transaction cancellation processing, cancellation processing is executed one by one according to the history, so that the cancellation processing is not performed. There was a problem that it took a lot of time to complete.

On the other hand, according to the method disclosed in Japanese Patent Laid-Open No. 2000-163372, when transactions are executed in parallel by branching, IDs are assigned to the paths of the transactions (P1, P2, P3) as shown in FIG. As shown in 11, the path ID and the processing name are stored in the execution history information of each processing constituting the transaction. Thus, when a failure occurs in the processing after the parallel execution, the execution history information can be traced in reverse order for each path using the ID assigned to the path as a key, and the cancellation processing can be started in parallel. (FIG. 10B).

[0008]

Generally, the processing that must be canceled differs depending on where a failure has occurred in a series of processing. Therefore, there is a trouble to manage a complicated cancellation procedure different depending on the timing of the occurrence of the failure. That is, the reason why the cancellation processing based on the execution history as described above is effective is here.

However, in the above-described example, when the processing is canceled after executing the parallel transaction processing, the cancellation procedure is decided in each transaction, so that the cancellation processing is not performed according to the execution history. Can be executed at high speed. Nevertheless,
According to the method disclosed in Japanese Patent Application Laid-Open No. 00-163372, the cancellation process using the history is uniformly applied to the transaction after the execution is completed, so that it takes time to execute the cancellation process.

[0010] The present invention has been made in view of such circumstances, and can efficiently cancel transactions of a plurality of different scenarios that are called in a branch from the same scenario and are processed in parallel. Transaction processing device, transaction processing method of the device,
An object of the present invention is to provide a transaction processing program and a computer-readable recording medium on which the program is recorded.

[0011]

In order to achieve the above-mentioned object, the present invention provides a transaction processing apparatus for processing a transaction composed of a series of plural processes according to a scenario describing a processing procedure. After a plurality of transactions of another scenario called from the scenario are processed in parallel, when a failure occurs during the transaction processing of the scenario of the caller, the transaction of the another scenario processed in parallel is executed. The present invention is characterized by comprising a cancellation processing means for canceling the constituent processes collectively by executing a cancellation process associated with each transaction one by one in advance.

In the present invention, when an execution history for each process is acquired at the time of executing a transaction, a cancellation process is defined for each history element. Then, when the cancellation processing is performed in the reverse order of the history, if the cancellation processing is associated with the history element, it is activated. This allows
It is possible to efficiently cancel a plurality of processes executed in parallel collectively.

[0013]

An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram showing a configuration of a scenario control system according to an embodiment of the present invention.

[0014] The scenario control system according to this embodiment comprises:
According to a scenario in which a business processing procedure is described, a transaction composed of a series of plural processes is processed. As shown in FIG.
1, receiving adapter 102, message management program 1
03, each processing unit of the scenario control program 104 and the transmission adapter 105, and the scenario management DBMS 121
And each data section of the scenario repository 122. The servers 130 in the figure are existing server systems to be linked by the scenario control system.

The request reception program 101
0 is a program that receives a request message for processing from 0, selects an appropriate receiving adapter 102 according to an identifier included in the request message, and passes the request message to the selected receiving adapter 102. Generally, identifiers such as Service and Action are embedded in the request message, and the request receiving program 101 uses a correspondence table or the like corresponding to the identifier to receive the reception adapter 1.
Select 02. That is, an appropriate receiving adapter 102 is selected and activated according to the type of the received message.

The receiving adapter 102 receives the message transmitted from the server 130 from the request receiving program 101, performs a process such as protocol conversion, and then issues a scenario start request or an execution request to the message management program 1.
The program is transmitted to the scenario control program 104 via the program 03. Generally, a plurality of the receiving adapters 102 exist, and are activated by the request receiving program 101. As described above, a scenario is a document that describes a procedure of a business process, and a scenario can be uniquely specified by a name.

The message management program 103 is a program generally known as an MQ (Messaging Queue), which temporarily stores transmitted messages, and
This is a program that transmits to a designated destination in the order of IFO (First In First Out).

The scenario control program 104 is a program that plays a central role in the scenario control system 100. The scenario control program 104 accesses the scenario repository 122 to acquire description information of the scenario, and is a work area used when executing the scenario. -It manages instance information (hereinafter referred to as instance information) and starts, executes, and terminates scenarios. Further, the scenario control program 104 includes the activity management program 10
6, a history management program 107 and a cancellation processing control program 108.

The activity management program 106
This is a program that holds a correspondence between an identifier indicating each process (hereinafter, referred to as an activity) constituting a transaction and a physical name of a program to be specifically activated.

The history management program 107 is a program that holds execution history information for each activity in association with an instance ID described later. The execution history information consists of a request message sent to the activity, a response message received as a result, information for referencing child history information, a history serial number, and an execution position (scenario name, state name) on the scenario. You. The history serial number is a number indicating the execution order of each activity.

The cancellation processing control program 108 is a program for evaluating the history information acquired from the history management program 107 and executing the cancellation processing.

The transmission adapter 105 is connected to the server 1
30 is a program that governs communication with the system 30. Generally, a plurality of programs exist. The transmission adapter 105 performs protocol conversion or the like in accordance with the protocol of the server 130, and requests the server 130 for processing. If the processing is of the synchronous type, processing for acquiring a response message as a processing result is also performed.

As described above, JP-A-2000-1633
In the method disclosed in Japanese Patent Application Publication No. 72-72, the cancellation processing is executed one by one by going backward in the execution history in parallel for each execution path. In other words, even if the canceling procedure is determined in each transaction, it takes a long time to execute the canceling process using the history uniformly, even if the procedure is fixed.

On the other hand, in this scenario control system 100, as shown in FIG. 2, for a transaction after completion of the processing, a cancellation processing capable of canceling the processing altogether regardless of the execution history. And run
It is possible to efficiently cancel a plurality of processes collectively (for example, three processes of S11, S12, and S13 are canceled by one cancellation process of S1 '). FIG. 3 is a diagram showing the configuration of the execution history information for FIG.

FIG. 4 is an example of a scenario describing a business processing procedure used as an example in the present embodiment. The scenario describes the execution procedure of each process constituting the transaction.

In the figure, each circle represents a state. This state is associated with a specific activity. Further, execution of a state means execution of an activity associated with the state. A scenario is composed of a plurality of states, and is interpreted and executed by the scenario control program 104.

The scenario describes a procedure (sequential, selection, repetition) in a business process, a method of evaluating a request message transmitted for each activity, or a response message received as a result. Then, as a result of the evaluation of the response message, a state to be executed next is determined, and a series of business procedures are achieved by repeating these.

In this example, first, the state Sp of the scenario F1 is executed. The execution of the state Sp calls the scenario F2 and activates the activities respectively associated with the states S1, S2, and S3 in parallel. In this parallel execution, a wait is performed until all activities are completed.

Each of the states S1, S2, S3 represents a call of a child scenario, and activates scenarios F3, F4, F5. The scenarios F3, F4, and F5 are respectively F3: S11 → S12 → S13 and F4: S
The process is started in the order of 21 → S22 → S23, F5: S31 → S32.

For each state, a state indicating the cancellation processing at the same time as the activity in the normal state, and an identifier of the cancellation processing program may be specified in association with the state.

Hereinafter, a table used in the present embodiment will be described.

<Execution History Information Management Table> The execution history information management table is a table for holding a history of execution of the processing constituting the transaction, and includes an instance ID, a serial number, a scenario name, a state name, a request message and a response message. Will be retained. One row in this table is called an execution history element.

Instance ID: At the time of scenario generation,
A unique identifier given to the work area (scenario instance) when executing the scenario.

Sequence number: An identifier assigned to each execution history element of the execution history information. It is unique for the instance ID. It is used to maintain the execution order of processing.
It has information to refer to the history element, and implementation using a unidirectional list or bidirectional list is also conceivable.

Scenario name, state name: Indicates the processing executed at the time of writing this history. The position on the scenario can be uniquely specified by a set of the scenario name and the state name. If this value is not written in the execution history element, it indicates that this processing has not been completed yet.

Request message: input information for each process given by the scenario. Input parameters.

Response message: Each process (server 130
Etc.) and output information indicating the processing result returned from. Output parameters. Information such as a transaction ID used when canceling processing according to history information is included.

<Execution History Parent-Child Information Management Table> The execution history parent-child information management table is a table for managing the hierarchical relationship between the execution history information.
A plurality of pieces of execution history information are associated as children. In the execution history parent-child information management table, a child instance ID and an instance ID are held.

Child instance ID: instance ID
The child instance ID that is a child of

Instance ID: Information for referring to the instance ID in the execution history information management table.

Next, the overall processing flow of the scenario control system 100 will be described.

(1) Request reception The request reception program 101 receives a processing request message from the server 130, and selects an appropriate reception adapter 102 according to the identifier included in the request message.

(2) Scenario activation request The selected receiving adapter 102 inputs a scenario name to the scenario control program 104 and issues a scenario activation request. On the other hand, the scenario control program 104
Secures instance information which is a work area when executing the scenario. At this time, an identifier indicating the currently executing instance information is returned to the receiving adapter 102 as a result of the scenario activation request. Hereinafter, an execution request is issued to the scenario using the identifier as a key.

(3) Scenario Startup The scenario control program 104 interprets a scenario in which a business process procedure is described, and manages the execution state of the scenario, such as starting, stopping, and executing the scenario, and the execution history of transaction processing. . When a scenario start request is received, the scenario control program 104 secures instance information, which is a work area when executing a scenario, and assigns a unique identifier (instance ID) to the area. Then, the scenario control program 104 obtains information on the scenario from the scenario repository 122, obtains a state to be executed first, and holds this as a current execution position.

The scenario control program 104 includes:
An execution history element corresponding to the instance is created, and a scenario name and a state name are written as an execution position.

(4) The scenario control program 104 which has received the message from the scenario execution receiving adapter 102 performs the following processing.

A. It is determined whether the received message includes failure information. If the received message includes the failure information, it indicates that the processing has failed, and the transaction rollback is triggered, and “processing when a failure occurs” is started.

B. The received message is written as a response message to the current history position.

C. The scenario F, which is the transmission destination of this message, is obtained from the scenario repository 122.

D. The message is evaluated according to the description of the scenario, and processing such as conditional branching is performed. As a result, a state name to be executed next is determined, and a request message for a program associated with the state is determined.

E. An identifier is assigned to the new execution history element, added to the history information, and a request message is written to the history element.

F. d. Executes the activity associated with the state determined in.

G. The scenario name,
Write the state name. If a cancellation process is associated with the state, that is also written.

(5) The activity execution scenario control program 104 passes the program identifier associated with the state S to the activity management program, and sends specific activity information (physical name of the program to be executed, object reference of the adapter, etc.) ) To get. The form of activity execution is
There are “program execution”, “(parallel) scenario execution”, and “return”.

In the case of “execution of a program”, for example, the transmission adapter 105 is activated and a message is transmitted to the server 130. As a result, in the case of synchronous processing, a response message may be obtained.

In the case of “scenario execution”, a new instance ID is issued according to the “scenario activation” process,
Create new execution history information. Further, in order to maintain the parent-child relationship of the history information, the parent instance ID and the newly issued instance ID are written in the execution history parent-child information management table.

In the case of “return”, a response message is transmitted to the parent scenario.

(6) Processing at the time of occurrence of a failure According to the scenario shown in FIG.
FIGS. 5 and 6 show an example of the execution history information management table and an example of the execution history parent-child information management table when a series of transactions are executed. As shown in FIG. 5, the execution of the processing is not completed (instance ID, serial number) = (1,
The scenario name and state name for the execution history information element of 2) are null values.

FIG. 7 shows a flowchart of a process when a failure occurs.

<Process 1 at the Time of Failure Occurrence> When the Cancellation Process Sp 'for the State Sp is Defined in FIG. 4 During the execution of the process associated with the state S of the scenario F1 shown in FIG. The following describes the cancellation processing when a failure occurs.

The message containing the failure information is sent to the server 13
0 is notified to the receiving adapter 102 as a message. In the case of a communication failure or the like, the receiving adapter 102 may generate a message including exception information. And
The reception adapter 102 has a scenario control program 104
A message containing the failure information. Hereinafter, a message including fault information is simply referred to as an exception. An exception indicates a failure during transaction processing, and is a trigger for rollback of transaction processing.

The scenario control program 104 to which the exception has been notified activates the cancellation processing control program 108 for canceling the failed instance ID.

The cancellation processing control program 108 searches the execution history information management table of FIG. 5 for a serial number corresponding to the instance ID, acquires the maximum value max, and sets the maximum value max as the current execution position pos (step A1).

An attempt is made to obtain an identifier of the cancellation processing program from the history element line. When the identifier of the cancellation processing program can be obtained (YES in step A2), a cancellation program corresponding to the identifier is obtained from the activity management program 106 and executed (step A3). The cancellation program is provided with information for referring to the execution history element, and executes a cancellation process using the request message and the response message in the information. Typically, the transaction ID returned from the server 130 is stored in the response message, and the cancellation program requests the server 130 for cancellation processing using the transaction ID as a key. In the case of this example, the cancellation processing program identifier Sp ′
Is defined, the activity associated with Sp ′ is executed.

Thereafter, 1 is subtracted from the current position pos on the history information (step A7), and the above processing is repeated until the beginning of the history information. If the cancellation processing has been executed up to the top of the history information (YES in step A8), exception information is notified to the parent instance of this instance (step A9). If the scenario is at the top of the parent-child hierarchy, the process ends without doing anything.

<Process 2 when Failure Occurs> When the cancellation process Sp ′ for the state Sp is not defined, the scenario control program to which an exception has been notified is a cancellation process control program for performing the cancellation process for the instance ID in which the failure has occurred. Execute

The cancellation processing control program searches the execution history information management table of FIG. 5 for the serial number corresponding to the instance ID, acquires the maximum value max, and sets the maximum value max as the current execution position pos (step A1).

An attempt is made to obtain an identifier of the cancellation processing program from the history element line. If the identifier of the cancellation processing program cannot be obtained (NO in step A2), the executed processing for the child scenario is canceled.

Therefore, a list of the child instance IDs corresponding to the instance ID 1 and the serial number 1 in the execution history parent-child information management table shown in FIG. 6 is obtained (step A4), and a process for canceling each instance ID is started. In the case of this example, there are three child instance IDs 2, 3, and 4 corresponding to the instance ID 1 and the serial number 1. Hereinafter, cancellation processing is performed on these three in parallel. For parallel implementation, for example, there is a method of starting a plurality of threads.

Hereinafter, similarly, the instance IDs 2, 3, and 4
The processing at the time of the failure occurrence is applied to. here,
The process related to the instance ID 2 will be described.

The cancellation processing control program searches the execution history information management table of FIG. 5 for a serial number corresponding to the instance ID, acquires the maximum value max = 1, and sets the maximum value max = 1 as the current execution position. Next, it is checked whether a cancellation processing program identifier is defined for the corresponding history line (step A).
2).

In this example, since S1 'is defined, a cancellation processing program corresponding to S1' is started.

The above process is repeated until 1 is subtracted from the current position pos on the history information and the beginning of the history information. When the cancellation process is executed up to the beginning of the history information, exception information is notified to the parent instance of this instance.

As described above, the scenario control system 1
In the case of 00, whether to use the history or to perform the batch cancellation processing is determined depending on whether or not the identifier of the cancellation processing program is defined. That is, according to the scenario control system 100, it is also possible to collectively and efficiently cancel a plurality of processes without depending on the history.

The present invention is not limited to the above-described embodiment, and can be variously modified in the implementation stage without departing from the gist of the invention. Further, the embodiments include inventions at various stages, and various inventions can be extracted by appropriately combining a plurality of disclosed constituent elements. For example, even if some components are deleted from all the components shown in the embodiment, the problem described in the section of the problem to be solved by the invention can be solved.
In the case where the effects described in the section of the effects of the invention are obtained, a configuration from which this configuration requirement is deleted can be extracted as an invention.

[0076]

As described above, according to the present invention, at the time of executing a transaction, when the execution history of each process is acquired, the cancellation process is defined for each history element. Then, when the cancellation processing is performed in the reverse order of the history, if the cancellation processing is associated with the history element, it is activated. This makes it possible to activate a process for canceling a plurality of processes executed in parallel at once.

[Brief description of the drawings]

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

FIG. 2 is an exemplary view showing an example of a hierarchically structured transaction including parallel execution processing according to the embodiment;

FIG. 3 is a diagram showing a configuration of execution history information for FIG. 2;

FIG. 4 is an exemplary view showing an example of a scenario describing a business processing procedure used as an example in the embodiment;

FIG. 5 is an exemplary view showing an example of an execution history information management table when the scenario control system of the embodiment executes a series of transactions.

FIG. 6 is an exemplary view showing an execution history parent-child information management table when the scenario control system according to the embodiment executes a series of transactions.

FIG. 7 is an exemplary flowchart showing the flow of processing when a failure occurs in the scenario control system of the embodiment.

FIG. 8 is a first diagram illustrating an example of a conventional parallel execution process and a first cancellation process according to an execution history.

FIG. 9 is a second diagram illustrating an example of a conventional parallel execution process and a first cancellation process according to an execution history.

FIG. 10 shows a conventional parallel execution process and a second process according to an execution history.
FIG. 7 is a first diagram for explaining an example of the cancellation processing of FIG.

FIG. 11 shows a conventional parallel execution process and a second process according to an execution history.
FIG. 9 is a second diagram for describing an example of the cancellation processing of FIG.

[Explanation of symbols]

100 ... scenario control system 101 ... request reception program 102 ... Reception adapter 103: Message management program 104: scenario control program 105 ... Transmission adapter 121: Scenario management DBMS 122 ... Scenario repository 130 ... Server

   ────────────────────────────────────────────────── ─── Continuation of front page    (72) Inventor Koji Tokumaru             2-3-1 Otemachi, Chiyoda-ku, Tokyo Sun             Within the Telegraph and Telephone Corporation (72) Inventor Masaki Suzuki             2-3-1 Otemachi, Chiyoda-ku, Tokyo Sun             Within the Telegraph and Telephone Corporation F term (reference) 5B085 AA08 AC03 AC16 BA07 BG04                       BG07                 5B098 GA04 GC16 JJ02 JJ06 JJ08

Claims (24)

[Claims] According to a scenario describing a processing procedure,
In a transaction processing apparatus that processes a transaction composed of a series of multiple processes, after a plurality of different scenarios of a transaction that are called from the same scenario are processed in parallel, the transaction processing of the calling scenario is performed. When a failure occurs, the processes constituting the transactions of the different parallel-processed scenarios are collectively executed by executing a cancellation process associated with each transaction one by one in advance. A transaction processing device comprising a cancellation processing means for canceling the transaction. 2. The transaction processing apparatus according to claim 1, wherein the cancellation processing means starts the cancellation processing associated with each of the transactions of the different scenarios that have been processed in parallel. 3. The cancellation processing means according to claim 1, wherein, when there is a transaction to which cancellation processing is not associated among the transactions of another scenario processed in parallel.
3. The transaction processing apparatus according to claim 1, wherein a cancellation process previously associated with each process constituting the transaction is executed in reverse order according to the execution history of the transaction. 4. The method according to claim 1, wherein said cancellation processing means includes means for collectively canceling all the transactions of another scenario that have been processed in parallel by a cancellation processing associated with the transaction of the caller. Item 2. The transaction processing device according to Item 1. 5. The cancellation processing means, for a transaction for which the processing has been completed among the transactions of another scenario processed in parallel, performs each of the transactions constituting the transaction by a cancellation processing associated with the transaction. The processing is collectively canceled, and for a transaction that has not been completed, the respective processing is canceled one by one in the reverse order by the cancellation processing previously associated with each processing constituting the transaction. The transaction processing device according to claim 1, wherein 6. According to a scenario describing a processing procedure,
In a transaction processing device that processes a transaction consisting of a series of multiple processes, when a different scenario is called multiple times from the same scenario,
When acquiring the execution history of a transaction that is processed in parallel at each branch destination, history management that records, as an execution history element of the transaction process, an identifier indicating a cancellation process for collectively canceling processes constituting the transaction. Means for executing a cancellation process indicated by an identifier in the execution history acquired by the history management means when a failure occurs during the transaction processing of the caller after the transactions of the another scenario are processed in parallel. And a canceling means for collectively canceling each process constituting a transaction of another scenario which has been processed in parallel by using the transaction processing device. 7. According to a scenario describing a processing procedure,
In a transaction processing method of a transaction processing device for processing a transaction composed of a series of plural processes, after a plurality of transactions of another scenario called in a branch from the same scenario are processed in parallel, When a failure occurs during the transaction processing of the scenario, the processing that constitutes the transaction of another scenario that has been processed in parallel is executed with a cancellation processing that is previously associated with each transaction. A transaction processing method, comprising a cancellation processing step of canceling all at once. 8. The transaction processing method according to claim 7, wherein in the cancellation processing step, a cancellation processing associated with each of the transactions of the another scenario that has been processed in parallel is started in parallel. 9. The cancellation processing step comprises, when a transaction to which cancellation processing is not associated exists in another parallel-processed transaction of another scenario, configuring the transaction according to the execution history of the transaction. 8. The method according to claim 7, wherein the canceling process associated with each process is executed in reverse order.
Or the transaction processing method according to 8. 10. The method according to claim 1, wherein the cancellation processing step includes means for simultaneously canceling all the transactions of the different scenario which have been processed in parallel by the cancellation processing associated with the transaction of the caller. Item 8. The transaction processing method according to Item 7. 11. The cancellation processing step includes, among the transactions of another scenario that have been processed in parallel, for a transaction whose processing has been completed, each of the transactions constituting the transaction is executed by a cancellation processing associated with the transaction. Negatively cancel processing,
2. The transaction according to claim 1, wherein, for a transaction for which the processing has not been completed, the respective processing is canceled one by one in a reverse order by a cancellation processing previously associated with each processing constituting the transaction. Transaction processing method. 12. A transaction processing method of a transaction execution device for processing a transaction composed of a series of plural processes according to a scenario describing a processing procedure, wherein a plurality of different scenarios are called by branching from the same scenario. At this time, when acquiring the execution history of a transaction that is processed in parallel at each branch destination, an identifier indicating a cancellation process for canceling each process constituting the transaction at once is recorded as an execution history element of the transaction process. After a transaction of the different scenario is processed in parallel with the history management step, when a failure occurs during the transaction processing of the caller, the failure is indicated by an identifier in the execution history acquired by the history management unit. Using the cancellation process, Transaction processing method characterized by comprising the bucking step of canceling collectively each process configuring the transaction management has been another scenario. 13. A program applied to a transaction processing device that processes a transaction composed of a series of plural processes according to a scenario describing a processing procedure, wherein the transaction processing device branches from the same scenario. After a plurality of transactions of another scenario called in parallel are processed in parallel, when a failure occurs during the transaction processing of the scenario of the caller, each process constituting the transaction of the another scenario processed in parallel For executing a cancellation process associated with each transaction in advance by executing a cancellation process associated with each transaction one by one. 14. The non-transitory storage medium according to claim 13, wherein the cancellation processing unit activates, in parallel, cancellation processing associated with each of the transactions of the different scenario that have been processed in parallel. 15. When the cancellation processing means includes a transaction to which cancellation processing is not associated in another parallel-processed transaction of another scenario, configures the transaction according to the execution history of the transaction. 14. The method according to claim 13, wherein a cancellation process associated with each process is executed in reverse order.
Or the program according to 14. 16. The cancellation processing means according to the cancellation processing associated with the transaction of the caller,
2. The method according to claim 1, wherein all of the transactions of the different scenario processed in parallel are canceled collectively.
3. The program according to 3. 17. The transaction processing unit according to claim 13, wherein, among the transactions of the different scenario processed in parallel, the transaction for which the processing has been completed is executed by the cancellation processing associated with the transaction. If a transaction is canceled in batches and the transaction is not completed,
14. The program according to claim 13, wherein the respective processes are canceled one by one in a reverse order by a cancellation process previously associated with each process constituting the transaction. 18. A program applied to a transaction processing device that processes a transaction composed of a series of plural processes in accordance with a scenario describing a processing procedure, wherein the transaction device is branched from the same scenario. When a plurality of different scenarios are called, when acquiring the execution history of a transaction that is processed in parallel at each branch destination, an identifier indicating a cancellation process for canceling each process constituting the transaction at once is referred to as the transaction. History management means for recording as an execution history element of processing; execution history acquired by the history management means when a failure occurs during transaction processing of the caller after the transactions of the different scenario are processed in parallel. Cancellation process indicated by the identifier in And a program for functioning as a canceling means for collectively canceling each process constituting a transaction of another scenario which has been processed in parallel. 19. A program applied to a transaction execution device that processes a transaction composed of a series of multiple processes in accordance with a scenario describing a processing procedure, wherein the transaction device is branched from the same scenario. After a plurality of called transactions of the different scenarios are processed in parallel, when a failure occurs during the transaction processing of the calling scenario, each of the processes constituting the transactions of the another processed parallel scenario is executed. A computer-readable recording medium in which a program for executing a cancellation process means for executing a cancellation process associated with each transaction one by one in advance to collectively cancel each transaction is recorded. 20. The computer-readable medium according to claim 19, wherein said program causes said cancellation processing means to activate in parallel the cancellation processing associated with each of said transactions of said another scenario that has been processed in parallel. Possible recording medium. 21. The program according to claim 16, wherein, when there is a transaction to which cancellation processing is not associated among the parallel-processed transactions of another scenario, the cancellation processing means executes the transaction in accordance with the execution history of the transaction. 21. The computer-readable recording medium according to claim 19, wherein a canceling process previously associated with each process constituting a transaction is executed in reverse order. 22. The program, wherein the cancel processing means causes the cancel processing associated with the transaction of the caller to collectively cancel all the transactions of the different scenario that have been processed in parallel. 20. The computer-readable recording medium according to claim 19, wherein: 23. The program instructs the cancellation processing means to execute, for a transaction whose processing has been completed among the transactions of the another scenario processed in parallel, the cancellation processing associated with the transaction. Of the transactions that have not been completed, the respective processes are canceled one by one in the reverse order by the cancellation process previously associated with each process that constitutes the transaction. 2. The transaction processing apparatus according to claim 1, wherein 24. A program applied to a transaction execution device that processes a transaction composed of a series of plural processes according to a scenario describing a processing procedure, wherein the transaction device is branched from the same scenario. When a plurality of different scenarios are called, when acquiring the execution history of a transaction that is processed in parallel at each branch destination, an identifier indicating a cancellation process for canceling each process constituting the transaction at once is referred to as the transaction. History management means for recording as an execution history element of processing; execution history acquired by the history management means when a failure occurs during transaction processing of the caller after the transactions of the different scenario are processed in parallel. Cancellation process indicated by the identifier in And a computer-readable recording medium storing a program for functioning as a canceling means for collectively canceling each process constituting a transaction of another scenario which has been processed in parallel.