JP2000047986A - Transaction processing system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the message arrival waiting time in another process in the case of message transfer from one process to another process. SOLUTION: When a machine C receives a transaction message from a terminal, a transfer payment processing program 71 instructs a queue manager 75 and data base manager 77 to start (21) a distributed transaction through a transaction manager 72. The queue manager 75 enqueues (22) the message required for a machine D to perform transfer reception processing to a queue under the control of the queue manager 75. Next, the queue manager 75 performs transfer (221) of the said message immediately without waiting the completion of commit processing 244 as the processing of the second phase in two-phase commit processing of transfer payment transaction based on the transaction manager 72 according to the instruction from the transfer payment processing program 71.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a transaction processing system applied to an environment in which a plurality of processes cooperate to perform processing.

[0002]

2. Description of the Related Art Conventionally, there has been known a transaction processing system employing a two-phase (two-phase) commit method as shown in FIG. 1, which is applied to a bank transfer processing business. In the above system, upon receiving a transaction message from a terminal (not shown) to the machine A, the transfer payment processing program 1 accepts the transaction message and starts a transaction to the queue (Q) manager 5 and the database (DB) manager 7 through the transaction (Tr) manager 3. Instruct. In response to an instruction from the program 1, the Q manager 5 enqueues a message necessary for the transfer payment processing in the machine B into a queue under its management, and
The B manager 7 performs a transfer payment process to the DB 9 based on the message. The Tr manager 3 commits the distributed transaction to the Q manager 5 and the DB manager 7 using the two-phase commit protocol (steps S21 to S25). When the Q manager 5 transfers the processed message to the Q manager 15 of the machine B, the message is queued in a queue managed by the Q manager 15. In the machine B, the transfer payment processing program 11 sends the Q manager 1 through the Tr manager 13.
5 and the DB manager 17 are instructed to start a transaction. In response to an instruction from the program 11, the Q manager 15 dequeues the message from the queue,
The B manager 17 performs a transfer payment process to the DB 19 based on the message. The Tr manager 13 commits the distributed transaction to the Q manager 15 and the DB manager 17 using the two-phase commit protocol (steps S26 to S30).

[0003]

By the way, in the system having the above configuration, unless the processing operation of steps S21 to S25, which is the processing of the program 1 (machine A), is completed, the machine A is switched from the machine A shown in step S26. No message transfer to B is performed. Therefore, steps S28 to S28, which are processes on the program 11 (machine B) side,
There is a problem that the processing operation of 30 cannot be performed unless the processing operations of steps S21 to S26 are completed. Hereinafter, the above problem will be described in detail with reference to FIGS.

FIG. 2 is an explanatory diagram showing a more detailed processing sequence of the above system.

As shown in FIG. 2, in the system configured as described above, even if the program 1 enqueues a message (step S23), the message is stored in a queue on a memory placed under the control of the Q manager 5. And the program 11 cannot receive the message. The message transfer 442 (step S26) extends to the commit (44) to the queue and the process of writing the enqueued message to the disk 6 (441) as an extension of the commit process (4) (step S25) of the distributed transaction. It must be completed before it can be started. In addition, when transferring the message (step S26), the Q manager 15
Until the process of writing the message to the managed disk 16 (message writing (443)) is completed, the dequeue process of the message by the program 11 (step S28) cannot be completed. Therefore, since the transfer payment processing on the machine A side and the transfer payment processing on the machine B side are serialized, the above two processings cannot be performed in parallel.

FIG. 3 is a timing chart showing the processing operation of the above system.

[0007] In FIG. 3, in the commit process (4) by the Tr manager 3, the commit (44)
And and after the writing process (441) is completed,
It is specified that a message is transferred to the machine B (step S26), and then a message dequeue (response) by the program 11 is started. In other words, the processing operation shown in steps S21 to S25 executed on the machine A side, the processing operation shown in step S26 relating to both the machines A and B, and the processing operation shown in step S28 executed on the machine B side It is apparent from FIG. 3 that the processing operations shown in the response to S30 form a time series.

Accordingly, an object of the present invention is to reduce a message arrival waiting time in another process when transferring a message from one process to another process in an environment in which a plurality of processes cooperate with each other. It is in.

[0009]

A transaction processing system according to a first aspect of the present invention is applied to an environment in which a plurality of processes cooperate with each other, and one of the processes is connected to another process. After the message relating to the processing operation in the above is generated, the message is transferred to another process at the latest before the processing for guaranteeing the consistency of the transaction performed in one process ends.

According to the above configuration, before the processing for guaranteeing the consistency of the transaction performed in one process at the latest, the message relating to the processing operation in the other process is sent from one of the processes. Transferred to the other processes described above. Therefore, the message arrival waiting time in other processes can be reduced as compared with the conventional case.

In a preferred embodiment according to the first aspect of the present invention, a two-phase commit process is employed as a process for guaranteeing transaction consistency. The message transfer is performed before executing the two-phase commit process in one process. If you do this,
The message arrival waiting time in another process can be made extremely short, and the processing on one process side and the processing on the other process side can be performed in parallel.

In the above embodiment, the message is
After being enqueued in a queue that is one of the resources in one process, it is transferred to a queue that is one of the resources in the other process. The one process performs a predetermined process in parallel with performing the commit process, which is the second phase of the two-phase commit process, on the message enqueued in the queue, and compares the result of the predetermined process with the other process. Transfer to queue.

On the other hand, the other process enables the message to be dequeued at the same time as the message is transferred from the queue of the one process to the queue, and transfers the message to the nonvolatile recording medium. I try to write it. As a result, the time from when a message is transferred from the queue of the one process to when the other process dequeues the message can be reduced. It is to be noted that loss of the message is prevented by writing the message on the non-volatile recording medium.

At the same time as performing the prepare process, which is the first phase of the two-phase commit process, on the message transferred to the queue, the other processes determine the validity of the message. Therefore, the processing result transferred from one process and checked in that process is checked. This means that if the result of the above processing is
This is a necessary processing operation because the message written in the non-volatile recording medium becomes invalid. As a result of the above-described check, when the processing result in the one process is successful, the other process determines that the message is valid and continues the above-described prepare processing for the message.
On the other hand, when the processing result is unsuccessful, the other processes determine that the message is invalid and stop the above-described prepare processing for the message.

In a program medium according to a second aspect of the present invention, in an environment in which a plurality of processes cooperate with each other, after one of the processes generates a message related to a processing operation in another process, A computer is operated as each process in a transaction processing system characterized in that a message is transferred to another process before processing for guaranteeing transaction consistency performed by at least one process ends at the latest. Computer-readable program.

[0016]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Before describing the embodiments of the present invention, an example of a general distributed transaction employing a two-phase commit method will be described with reference to FIGS. In the two-phase commit method, as shown in FIG.
This is to ensure the consistency of transactions that are distributed to a plurality of resources such as databases and queues.

FIG. 4 is a functional block diagram showing the configuration of a general distributed transaction processing system employing a two-phase commit method.

As shown in FIG. 4, the system includes a business processing program 41 for executing a business and a transaction manager (Tr manager) 43 for managing the execution of a distributed transaction as main components (modules). Prepare. The above system further includes a resource (queue) manager (Q manager) 45 for managing a queue (queue) for transmitting and receiving messages, and a resource (database) manager (DB manager) for managing a database in addition to the above-described units. 47 is also provided.

The interfaces between the above modules include a transaction control interface 49 for instructing the Tr manager 43 to perform transaction control from the program 41, and a message transmission / reception between the program 41 and the Q manager 45. There is a Q access interface 51. Program 4
Database access interface 53 such as SQL for transmitting and receiving messages between the client 1 and the DB manager 47
There is also. Further, the Tr manager 43 is executed from the program 41.
Tr manager 43 actually responds to the control request to
There are also XA interfaces 55 and 57 for performing distributed commit control of transactions between the manager 45 and the DB manager 47 according to a two-phase commit protocol. The XA interfaces 55 and 57 are connected to the Tr manager 43, the Q manager 45 and the DB manager 47.
X / Open is defined as an interface with a resource manager such as this.

FIG. 5 is an explanatory diagram showing a processing sequence of the above-described system. The processing sequence shown in FIG.
This is when transfer processing is performed between two DBs.

In FIG. 5, when the program 41 instructs the “transaction start” to the Tr manager 43 (step S61), the Tr manager 43 responds to the instruction by the DB manager A 47 and the DB manager B.
A transaction start instruction (11) is issued to each of the processors 59. A transaction start DB A (111) is executed for the DB manager A47, and a transaction start DB B (112) is executed for the DB manager B59, and the processing results are notified to the program 41.

Next, the program 41 instructs the DB manager A 47 to "update DB A (12)" to perform the transfer payment processing. In DB manager A47,
A predetermined process is performed based on the instruction, and the processing result is notified to the program 41 (step S62). Similarly,
The program 41 instructs the DB manager B59 to "update DB B (13)" in order to perform the transfer payment processing. The DB manager B59 performs predetermined processing based on the instruction, and notifies the program 41 of the processing result (step S63).

Next, the program 41 instructs the Tr manager 43 to execute "transaction commit (14)". The Tr manager 43 sends the DB
A series of transaction commit processing described below is performed on the manager A 47 and the DB manager B 59 (step S64).

First, the Tr manager 43 instructs the DB manager A 47 to perform a prepare process (141). Upon receiving this instruction, the DB manager A 47 performs a “prepare process”, which is the first phase for committing the corresponding transfer payment transaction, according to the two-phase commit protocol. In this process, the DB manager A47 logs “information necessary for committing the relevant transfer payment transaction” and “result of the prepare process (success / failure)” on a non-volatile recording medium such as a disk. After that, the Tr manager 43 is notified of the result of the prepare processing.

Next, the Tr manager 43 instructs the DB manager B59 to perform a prepare process (142). Upon receiving this instruction, the DB manager B59 performs “prepare processing”, which is the first phase for committing the corresponding transfer deposit transaction, according to the two-phase commit protocol. In this process, the DB manager B59 logs “information necessary for committing the relevant transfer deposit transaction” and “result of the prepare process (success / failure)” to a non-volatile recording medium such as a disk. After that, the Tr manager 43 is notified of the result of the prepare processing.

Next, the Tr manager 43 commits or rolls back the corresponding transfer transaction based on the result of the prepare process notified from the DB managers A 47 and 59 (commit / roll back).
Is determined (143). That is, DB manager A4
If both of the prepare processes for 7, 59 are successful, "commit" is set; otherwise, "roll back" is set.
And Further, the Tr manager 43 writes the determined result as a “decision log” on a non-volatile recording medium such as a disk. In the following description, a case where the relevant transfer transaction is committed will be described as an example.

First, the Tr manager 43 instructs the DB manager A 47 to perform a commit process (144). In accordance with the two-phase commit protocol, the DB manager A 47 performs a "commit process", which is the second phase for committing the transfer payment transaction. During this process, the DB manager A47 commits the relevant transfer payment transaction and logs the result of the commit process on a non-volatile recording medium such as a disk. afterwards,
The result of the commit process is notified to the Tr manager 43.

Next, the Tr manager 43 instructs the DB manager B59 to perform a commit process (145). In accordance with the two-phase commit protocol, the DB manager B59 performs “commit processing”, which is the second phase for committing the transfer deposit transaction. In this process, the DB manager B59 commits the transfer transaction and logs the result of the commit process to a non-volatile recording medium such as a disk. afterwards,
The result of the commit process is notified to the Tr manager 43.

Further, the Tr manager 43 writes the processing result of the corresponding transfer transaction to a non-volatile recording medium such as a disk based on the commit processing result notified from the DB managers A 47 and B 59 (14).
Perform 6). That is, when the commit processing for the DB managers A 47 and 59 is both successful, it is determined as “success”,
In other cases, a recovery process is performed between the Tr manager 43 and the DB managers A 47 and 59. When the Tr manager 43 completes a series of two-phase commit processing,
The processing result is notified to the program 41.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

FIG. 6 is an explanatory diagram showing a processing sequence when the transfer payment processing is successful in the transaction processing system according to one embodiment of the present invention.

The above system is applied to a bank transfer processing business including a transfer payment processing and a transfer deposit processing.
A two-phase commit method is adopted, and a machine C that functions as a client that performs a transfer payment process as shown in the figure.
D that functions as a server that performs transfer and transfer payment processing
It has. The configuration of the above system is basically the same as the configuration of the conventional system shown in FIG.

The machine C has a transfer payment processing program 7
1, a Tr manager 72, disks 73 and 74 placed under the control of the manager 72, and a Q manager 75
And a disk 76 placed under the control of the manager 75. Machine C also has a DB manager 7
7 and programs 71 and T under the control of the manager 77
A DB 78 accessed by the r manager 72 and a disk 79 are also mounted.

On the other hand, in the machine D, a transfer payment processing program 81, a Tr manager 82, disks 83 and 84 under the control of the manager 82, a Q manager 85, and a disk under the control of the manager 85 8
6 is mounted. The machine D further includes a DB manager 87, a DB 88 accessed by the program 81 and the Tr manager 82 under the control of the manager 87,
And a disk 89.

In the above configuration, when the machine C receives a transaction message from a terminal (not shown), the program 71 instructs the Q manager 75 and the DB manager 77 through the Tr manager 72 to start a distributed transaction (21) ( Step S9
1). As a result, first, the Q manager 75
Enqueue (22) a message necessary for performing the transfer payment processing in a queue managed by the Q manager 75 (step S92). When this processing operation is completed, Q
The manager 75 receives an instruction from the program 71,
The message transfer (221) is immediately performed without waiting for the completion of the commit process (244), which is the second phase of the two-phase commit process in the transfer payment transaction by the Tr manager 72.

On the other hand, the program 81 is the Tr manager 8
2 through Q manager 85 and DB manager 87
Is instructed to start a distributed transaction (21) (step S95). The above message is Q Manager 7
5 arrives at the queue of the Q manager 85, the message is immediately sent to the program 81.
(Step S96). In parallel with the message dequeue process (26), the Q manager 85 also writes (222) the message to the disk (non-volatile recording medium) 86. Note that this write processing (2
If the above message is lost before the completion of 22) due to a malfunction such as a down of the machine D, the machine (C) determines the machine based on the information (message) stored in the disk (non-volatile recording medium) 76 on the machine C side. The message can be restored on the D side.

Next, according to an instruction from the program 81, D
DB8 based on the above message by B manager 87
After the transfer payment processing to No. 8 has been performed (step S97),
The Tr manager 82 commits the distributed transaction to the Q manager 85 and the DB manager 87 using a two-phase commit protocol (step S98). That is, for the Q manager 85, the prepare Q (28
As 1), a prepare process (2811), which is the first phase of the commit process of the corresponding transaction, is performed. At this time, the Q manager 85 determines whether the message dequeued by the Tr manager 82 is valid or not.
The transaction processing result (2441) transferred from the machine C through the Q manager 75 is examined. The reason for performing this check is that if the Tr manager 72 rolls back the transaction processing result as a failure as described later, the message dequeued by the program 81 becomes invalid. Note that machine C
If the transaction processing result (2441) has not been transferred from, the Q manager 85 waits until the message is transferred.

Here, returning to the machine C again, after the transfer payment processing to the DB 78 based on the above message is performed by the DB manager 77 in accordance with the instruction from the program 71 (step S93), the Tr manager 72 becomes the Q manager 75. Then, the distributed transaction is committed to the DB manager 77 by the two-phase commit protocol (step S94). For the Q manager 75, the commit process which is the second phase of the commit process of the corresponding transaction as the commit Q (244), that is, the transfer of the transaction process result (commit (success) / rollback (fail)) (2441) ).

On the other hand, on the machine D side, the Q manager 75
Is transmitted (2441) as a transaction processing result, the Q manager 85 notifies the Tr manager 82 as a result of the prepare Q (281), and the Tr manager 82 ,
The dequeued message is determined to be valid. As a result, the Q manager 85 continues the prepare process (2811) for the message. The Q manager 85, as a result of the prepare Q (281),
The processing result (success) of the prepare processing (2811) is represented by T
r manager 82, and after receiving the notification, T
The r manager 82 uses the normal two-phase commit protocol (2
84) to (286) are executed.

FIG. 7 is a timing chart showing a processing operation when the transfer payment processing in the above system is successful.

According to FIG. 7, the message arrival waiting time on the machine D side is determined by the message (221) transferred from the Q manager 75 after the program 81 issues the message dequeue request (261) in step S96. This is the time until the message arrives, and is extremely short as compared with the message arrival time shown in FIG.

FIG. 8 is an explanatory diagram comparing the timing at which the transfer manager Q on the transfer payment side and the conventional Q manager 5 on the transfer payment side perform message transfer and transaction process result transfer, respectively.

As shown in FIG. 8, the present embodiment differs from the prior art in that when the enqueue (22) of a message necessary for performing the transfer payment processing is completed in the machine D, the message transfer (221) is immediately performed. Is different from Also, in order to notify the Q manager 85 of the transaction processing result on the transfer payment side (machine C side), the transfer processing (commit / rollback) of the transaction processing result (commit / rollback) (2441) is newly added. Is different from

FIG. 9 shows the Q manager 8 on the transfer deposit side.
FIG. 5 is an explanatory diagram comparing a timing at which a transfer manager 5 and a conventional transfer manager Q manager 15 dequeue a message and a timing at which it is determined whether or not the message is valid.

As shown in FIG. 9, in the present embodiment, the message dequeue (2
6) and the writing of the message in the queue to the disk 86 (222) is different from the prior art in that it is processed in parallel. Further, the transferred transaction processing result (24
This is also different from the related art in that a judgment process by the Q manager 85 of the result of the write process (2442) of the process 41) to the disk 86 (2442) and the process of the prepare process (2811) performed in parallel therewith is added.

FIG. 10 shows a processing operation performed between the Q manager 85 in the machine D and the program 81, and is an explanatory diagram showing a state when the transfer payment transaction is committed (successful).

As shown in FIG. 10, when the Q manager 85 receives the message (MsgA) transferred from the machine C side (221), the MsgA is dequeued by the program 81 in a queued state (26). Substantially in parallel with this processing operation, MsgA is also written to the disk 86 (222).

When the Q manager 85 receives the transaction processing result (2441) transferred from the machine C side, the processing result (message status) is set as commit A by the program 81 in the prepare processing (281).
Transaction commit processing (28) including 1) and commit processing (2841) is performed. In parallel with this, the above processing result is written to the disk 86 (2442).
Is also performed.

FIG. 11 is an explanatory diagram showing a processing sequence when the transfer payment processing has failed in the transaction processing system according to one embodiment of the present invention.

The processing sequence shown in FIG. 11 is performed until the Tr manager 82 causes the Q manager 85 to examine the transaction processing result (2441) from the machine A in order to determine whether the dequeued message is valid. , The processing sequence described with reference to FIG. Therefore, hereinafter, a processing sequence when “rollback (failure)” is transferred (2441) as the transaction processing result will be described.

When “Rollback (failure)” is transferred (2441) from the Q manager 75 on the machine A side to the Q manager 85 as a transaction processing result,
The Q manager 85 sends the dequeued message (2
6) is determined to be invalid. The Q manager 85
Is the prepare process (281) for the message.
1) is stopped, and the processing result (failure) of the prepare processing (2811) is notified to the Tr manager 82. Upon receiving the notification, the Tr manager 82 prepares the transfer deposit transaction for the queue which is one of the two resources (that is, the database and the queue) (the first phase process during the two-phase commit process). Will fail and roll back the transaction. As described above, by executing different processing operations according to (commit (success) / rollback (failure)) (2441) of the transaction processing result transferred from the machine A to the Q manager 85, for example, 4
The compatibility with the two-phase commit protocol such as the XA interface (55, 57) shown in FIG.

FIG. 12 shows a processing operation performed between the Q manager 85 and the program 81 in the machine D, and is an explanatory diagram showing a state when the transfer payment transaction is rolled back (failed).

As shown in FIG. 12, when the Q manager 85 receives the message (MsgA) transferred from the machine C side (221), the MsgA is dequeued by the program 81 in a queued state (26). Substantially in parallel with this processing operation, MsgA is also written to the disk 86 (222).

Next, when the Q manager 85 receives the rollback A as the transfer payment transaction processing result (message status) (2441) transferred from the machine C side, the Q manager 85 writes the processing result to the disk 86 (2442). In parallel, a transaction commit process (28) described below is performed. That is, program 8
In 1, the NG prepare process (2811) and the rollback process (2841) of the MsgA written to the disk 86 and the result of the transfer payment transaction process are performed.

FIG. 13 is an explanatory diagram showing a message recovery process performed in the machine D.

In FIG. 13, the Q manager 85 completes receiving the message MsgA from the machine C side (221).
After that, if the machine D goes down for some reason before the writing of MsgA to the disk 86 is completed,
The MsgA is lost. In this case, after the machine D returns to the normal state, the MsgA is restored by, for example, having the MsgA re-transferred from the disk 76 on the machine C side. Also, after the Q manager 85 completes the reception of the transfer payment transaction processing result from the machine C side (2442), if the machine D goes down for some reason before the writing of the processing result to the disk 86 is completed, the above processing is performed. The result is lost. In this case, after the machine D returns to a normal state, for example, the disk 76 on the machine C side
, The processing result is re-transferred, thereby restoring the processing result.

FIG. 14 is an explanatory diagram showing another mode of the message recovery processing performed in the machine D.
FIG. 14 shows an example of the recovery processing at the time of restarting after the machine D goes down for some reason before the writing of the transfer payment transaction processing result is completed in FIG.

In FIG. 14, when the system is restarted, the Q manager 85 of the machine D reads the message (31) and reads the result of the transfer payment transaction processing (32), thereby obtaining the Q of the machine C. A transmission request (33) of the transfer payment transaction processing result is made to the manager 75. Upon receiving the transmission request (51), the Q manager 75 reads the transfer payment transaction processing result including the rollback B from the disk 76 (52), and transmits the processing result to the Q manager 85 (53). Upon receiving the processing result (34), the Q manager 85 enqueues the processing result into a queue placed under the control of the Q manager 85 (35).
And further writes the processing result to the disk 86 (3
Execute 5).

In the above-described system, if a failure such as a machine (C, D) failure occurs between the start of transaction processing and the start of commit processing, the Q manager and Rollback processing is automatically performed under the responsibility of a resource manager such as a DB manager. Further, if a failure such as a machine (C, D) down occurs between the start of the two-phase commit processing of the transaction processing and the completion of the two-phase commit processing, the two-phase commit protocol is used. The Tr manager and the resource manager cooperate to perform a recovery process.

As described above, according to the embodiment of the present invention, when executing a transaction for a database or the like distributed on a plurality of machines, compatibility with the two-phase commit protocol is maintained. In addition, it is possible to reduce the delay time when executing a subtransaction in each machine. As a result, it is possible to enhance the concurrent execution of sub-transactions constituting a transaction between a plurality of machines.

It should be noted that the above-mentioned contents relate to one embodiment of the present invention, and do not mean that the present invention is limited to only the above-described contents.

[0062]

As described above, according to the present invention,
In an environment where multiple processes cooperate and process,
When transferring a message from one process to another process, the waiting time for message arrival in another process can be reduced.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an example of a conventional transaction processing system.

FIG. 2 is an explanatory diagram showing a detailed processing sequence of the system shown in FIG. 1;

FIG. 3 is a timing chart showing a processing operation of the system described in FIG. 1;

FIG. 4 is a functional block diagram showing a configuration of a general transaction processing system employing a two-phase (two-phase) commit method.

FIG. 5 is an explanatory diagram showing a processing sequence of the system described in FIG. 4;

FIG. 6 is an explanatory diagram showing a processing sequence when the transfer payment processing is successful in the transaction processing system according to the embodiment of the present invention.

FIG. 7 is a timing chart showing a processing operation when the transfer payment processing in the system shown in FIG. 6 is successful.

FIG. 8 is an explanatory diagram comparing timings at which the transfer payment processing side queue manager of FIG. 6 and the transfer payment processing side queue manager of FIG. 1 perform message transfer and transaction processing result transfer, respectively;

9 is an explanatory diagram comparing the timing of dequeuing a message and the timing of judging whether or not a message is valid, respectively, between the transfer deposit processing side queue manager of FIG. 6 and the transfer deposit processing side queue manager of FIG. 1;

FIG. 10 is an explanatory diagram showing a processing operation performed between a queue manager in a transfer payment processing machine and a transfer payment processing program.

FIG. 11 is an explanatory diagram showing a processing sequence when transfer payment processing has failed in the transaction processing system according to one embodiment of the present invention.

FIG. 12 is another explanatory diagram showing a processing operation performed between a queue manager in the transfer payment processing machine and a transfer payment processing program.

FIG. 13 is an explanatory diagram showing a message recovery process performed in the transfer payment processing machine.

FIG. 14 is an explanatory view showing another mode of the message recovery process performed in the transfer payment processing machine.

[Explanation of symbols]

71 Transfer payment processing program (program) 72, 82 Transaction manager (Tr manager) 73, 74, 76, 79 Disk 75, 85 Queue manager (Q manager) 77, 87 Database manager (DB manager) 78, 88 Database (DB) 81 Transfer payment processing program (program) 83, 84, 86, 89 Disk

──────────────────────────────────────────────────続 き Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI Theme coat ゛ (Reference) G06F 19/00 G06F 15/30 360

Claims (10)

[Claims] In an environment in which a plurality of processes cooperate with each other, one of the plurality of processes generates a message related to a processing operation in another process, and then performs the message in the one process at the latest. A transaction processing system wherein the message is transferred to another process before a process for guaranteeing transaction consistency is completed. 2. The transaction processing system according to claim 1, wherein the process for ensuring the consistency of the transaction is a two-phase commit process. 3. The transaction processing system according to claim 2, wherein the transfer of the message is performed before the one process executes a two-phase commit process. 4. The transaction processing system according to claim 1, wherein the message is enqueued in a queue that is one of resources in the one process and then is a queue that is one of resources in the other process. A transaction processing system characterized by being transferred to a transaction processing system. 5. The transaction processing system according to claim 1, wherein said one process is in a second phase of a two-phase commit process for a message enqueued in the queue. A transaction processing system, wherein a result of performing a predetermined process is transferred to a queue of the other process in parallel with performing the commit process. 6. The transaction processing system according to claim 1, wherein the other process is configured such that when the message is transferred from a queue of the one process to a queue of the other process. At the same time, so that the message can be dequeued, and
A transaction processing system wherein the message is written to a non-volatile recording medium. 7. The transaction processing system according to claim 1, wherein the other process is in a first phase during a two-phase commit process for the message transferred to the queue. Substantially at the same time as performing the prepare process, the process result of the one process transferred from the one process is checked to determine the validity of the message. Transaction processing system. 8. The transaction processing system according to claim 7, wherein the other process determines that the message is valid when the processing result of the one process is successful, and performs the prepare process on the message. A transaction processing system characterized by continuing. 9. The transaction processing system according to claim 7, wherein the other process determines that the message is invalid when the processing result of the one process is unsuccessful, and performs the prepare process on the message. A transaction processing system characterized by canceling. 10. In an environment in which a plurality of processes cooperate to perform processing, one of the plurality of processes generates a message relating to a processing job in another process, and then performs the message in the one process at the latest. A computer program for operating a computer as each of the processes in the transaction processing system, characterized in that the message is transferred to another process before the process for guaranteeing transaction consistency is completed. A computer readable program medium carried.