JP3621641B2 - Managing transaction processing - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a transaction processing management method applied to distributed processing used in a distributed processing environment.
[0002]
[Prior art]
In a distributed processing environment, server processes for performing various services are distributed on a plurality of computers.
[0003]
Therefore, when a client process on a certain computer wants to receive some service provided by another server process, it transmits a service request to the server process that provides the service. . At this time, in order to manage which server process on which computer the service to be received is provided, a process called a name server (Name Server) or a directory service (Directory Service) is conventionally used. Yes.
[0004]
The name server manages which server process provides what type of service. When a client process that wants to receive a service tells the service name, the server process that can execute the service. And the computer on which this server process exists. Some name servers have an attribute value for each service, and the capabilities are expanded by performing pattern matching based on the service name and attribute transmitted by the client process that wants to receive the service. Also exist.
[0005]
On the other hand, transaction processing is used for such distributed processing in order to increase the reliability of the system.
[0006]
Such transaction processing is executed in units called transactions, and one transaction crosses one or more processes such as application programs and database management systems and executes them. Thus, a series of processing is completed. At this time, a plurality of processes executing one transaction may be distributed to a plurality of computers coupled via a channel or a network. For example, as shown in FIG. 25, on a computer 34 that performs transaction processing, there are processes 342, 342,... For executing processing, and a transaction management unit 341 for managing processing. When performing transaction processing distributed to a plurality of computers, as shown in FIG. 26, a process and a transaction management unit 351 exist on each computer, and the transaction management unit 351 on each computer communicates with each other while communicating. Manage. The transaction manager controls the execution of each transaction so that it has the following properties.
(1) It is ensured that the atomicity process is completely executed until the end, or if the complete execution is impossible, the influence of the execution is not left.
(2) By performing a consistency process, it is ensured that a transition from a consistent state to a consistent state is made.
(3) Isolation Ensures that the results of multiple processes executed in parallel are the same as if they were executed in series in some order.
(4) Persistence (durability) The result of a fully executed process ensures that it will be recovered even if a failure occurs.
[0007]
In order to realize these, the transaction management unit performs commit processing after the processing of each transaction is completed. As a method of commit processing, two-phase commit is representative and often used. There are other methods that improve various two-phase commits, including three-phase commit.
[0008]
For example, FIG. 29 shows the operation of the two-phase commit method in the case of transaction processing by the transaction management unit 361 and the two processes 362 and 363 as shown in FIG. FIG. 29 shows the interaction between the components over time. Here, one transaction is processed by two processes of process 362 and process 363. When the transaction processing is completed, the transaction management unit 361 performs a commit process on all processes (in this case, the process 362 and the process 363) involved in the execution of the transaction. The commit process consists of two phases, a voting phase and a decision phase. First, the voting phase issues a VOTE-REQ request for inquiring whether each transaction can be committed, that is, correctly completed, to each process. Each process answers yes or no. If the answer is YES, each process records the transaction execution result in a log, makes the process result recoverable even if a failure occurs, and then responds YES. If there is some trouble or abnormality and processing cannot be performed normally, NO is returned. When a response of YES or NO is returned from all processes to the transaction management unit, the voting phase ends and the next decision phase is entered. Only when all processes answer YES, in the decision phase, the transaction manager issues a COMMIT request to each process. The process that has received the COMMIT request performs processing such as permanent data update, assuming that the corresponding transaction has been normally completed.
[0009]
If there is at least one process that responds NO in the voting phase, the transaction cannot be completed correctly. In such a case, an abort process is performed as shown in FIG. That is, in the decision phase, an ABORT request for instructing all processes to cancel the transaction is issued. The process that receives the ABORT request performs a process of canceling the update of data or the like by the corresponding transaction, and guarantees the atomicity of the transaction.
[0010]
27, 29, and 30 are examples when the process 362 and the process 363 are operating on the same computer. When the process 372 and the process 374 are operating on different computers as shown in FIG. 28, the transaction management unit 371 on the computer A issues a processing request to the transaction management unit 373 on the computer B as shown in FIG. The transaction management unit 373 performs commit processing on the process 374 on behalf of the transaction management unit 371.
[0011]
Transactions processed in this manner are independent processing units as shown in A, B... Of FIG.
[0012]
On the other hand, J.H. Eliot B. Nested transactions (Nested Transactions) disclosed in Moss' “Nested Transactions-An Applied to Reliable Distributed Computing” (The MITPress, 1985) include multiple transactions 421 to 4 as shown in FIG. This is a method for realizing one transaction as a combination of transactions in smaller units. Here, as shown in FIG. 34, the highest-level transaction 431 in the hierarchy is called a top-level transaction, and the lower-level transactions 432 to 434 are called sub-transactions. A top-level transaction and all sub-transactions below it are collectively referred to as a transaction family. In nested transactions, transaction families are treated the same as non-nested non-nested transactions, but subtransactions belonging to the same transaction family are guaranteed atomicity and independence in the same way as non-nested transactions. There are advantages in that they can be executed in parallel between sub-transactions, and aborts due to failures can be localized at the sub-transaction level.
[0013]
In order to execute a nested transaction, as shown in FIG. 36, a process 452 that can execute a nested transaction, a process 453 that cannot execute a nested transaction, and a transaction management unit 451 that can manage the nested transaction exist on the computer. Must. When the processes are distributed on a plurality of computers, as shown in FIG. 37, a process 462 and a transaction management unit 461 that can execute a nested transaction in each computer, and a process 464 and a transaction that cannot execute a nested transaction. A management unit 463 is placed.
[0014]
Unlike the case of a non-nested transaction, the commit processing of a nested transaction must cope with two cases of the commit processing of a top-level transaction and the commit processing of a sub-transaction. FIG. 38 and FIG. 39 show an example of the commit process of the nested transaction. Here, a case is considered in which both a top-level transaction T441 and its sub-transaction S442 as shown in FIG. 35 are executed by a process. FIG. 38 shows a case where two processes exist on the same computer and one transaction management unit manages them. FIG. 39 shows a case where each process exists on a different computer and is managed by a transaction management unit on each computer.
[0015]
First, the sub-transaction commit process is performed. In the examples of FIGS. 38 and 39, the transaction manager only records that the sub-transaction has been committed, and does not instruct the process. At the time of committing a sub-transaction, a method of doing nothing like this example is often used, but an implementation method in which processing similar to normal two-phase commit is performed on a sub-transaction is also possible.
[0016]
The commit process for the top-level transaction is the same as that for the non-nested transaction. However, when a top-level transaction commits, it is necessary to ensure that not only the data etc. updated by the top-level transaction but also the data etc. updated by all its sub-transactions are recorded permanently. is there. Similarly, if a top-level transaction aborts, all its subtransactions must be aborted. As described above, the committed state of the sub-transaction is only temporary, and there is a case where the state is overturned by a higher-level transaction. A process that can execute a nested transaction must be able to execute such processing in response to a request from the transaction management unit, and this is different from a process that cannot execute a nested transaction.
[0017]
[Problems to be solved by the invention]
In the conventional transaction processing method, in order to perform nested transaction processing, there must be a transaction manager capable of managing nested transactions and a process capable of executing nested transactions. Therefore, if a conventional database management system or application program process that cannot execute a nested transaction is used for the nested transaction processing, the process program must be rewritten so that the nested transaction can be executed. In addition, a conventional transaction management unit that cannot manage nested transactions and a computer that has a process that cannot manage nested transactions and a computer that has a transaction management unit that can manage nested transactions are combined. Transaction processing was impossible.
[0018]
The present invention has been made in consideration of the above circumstances, and can execute nested transaction processing even when there is a process that cannot execute a nested transaction or a computer having a transaction management unit that cannot manage a nested transaction. The purpose is to provide a transaction management method.
[0019]
[Means for Solving the Problems]
The present invention relates to a transaction processing management method (using a transaction management means capable of managing nested transactions) in a transaction processing system including a process capable of executing a nested transaction and a process not capable of executing a nested transaction. A sub-transaction of a nested transaction is executed by each of the executable process and the process that cannot execute the nested transaction, a commit process is performed on the sub-transaction executed by the process that can execute the nested transaction, and the top of the nested transaction is executed. Level transaction is executed, the executed top level transaction is committed, and the top level transaction is executed. Upon completion of commit processing of Le transaction, characterized in that to complete the commit processing for the sub-transactions performed by the nested transaction infeasible process.
[0020]
Preferably, the commit process for the sub-transaction executed by the process that cannot execute the nested transaction may be performed in parallel with the commit process for the top-level transaction.
[0021]
Preferably, the voting phase of the commit process for the sub-transaction executed by the process that cannot execute the nested transaction is performed in parallel with the commit process for the sub-transaction executed by the process that can execute the nested transaction, The determination phase of the commit process for the sub-transaction executed by the process that cannot execute the nested transaction may be performed in parallel with the commit process of the top-level transaction.
[0022]
Preferably, the voting phase of the commit process for the sub-transaction executed by the process that cannot execute the nested transaction is set to the commit process for the sub-transaction executed by the process that can execute the nested transaction and the top level of the nested transaction. It may be performed in parallel with the execution of the transaction, and the decision phase of the commit process for the sub-transaction executed by the process that cannot execute the nested transaction may be performed in parallel with the commit process of the top-level transaction.
[0023]
Preferably, the voting phase of the commit process for the sub-transaction executed by the process that cannot execute the nested transaction is performed in parallel with the execution of the top-level transaction of the nested transaction, and the process that cannot execute the nested transaction The determination phase of the commit process for the executed sub-transaction may be performed in parallel with the commit process of the top level transaction.
[0024]
As a result, according to the transaction processing management method of the present invention, for a sub-transaction executed without being aware that a process that cannot execute nested transaction processing is nested, the commit processing of the transaction is performed. Since the process of the deterministic process is delayed until the process of the deterministic process of the commit process of the top-level transaction, the transactional properties such as atomicity, persistence, consistency, and isolation of the transaction are not sacrificed. In addition, the voting phase of the commit process of a transaction executed by a process that cannot execute a nested transaction and the vote result of the voting phase of a commit process of a nested top-level transaction are combined to determine the possibility of determining both transactions. Therefore, the transactional properties such as atomicity, persistence, consistency, and isolation of the entire nested transaction can be guaranteed.
[0025]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
[0026]
A transaction processing method applied to the distributed processing described above will be described.
[0027]
(First embodiment)
FIG. 6 shows a case where the top-level transaction T and its sub-transaction S manage a process 122 that can execute a nested transaction and a process 123 that cannot execute a nested transaction by the transaction management unit 121 as shown in FIG. Shows the commit process.
[0028]
FIG. 2 shows the configuration of the transaction management unit 121 in this case. In this case, the transaction management unit 121 manages two tables, a process table 1211 and a transaction table 1212. The process table 1211 records whether or not a nested transaction can be executed for a process involved in transaction processing on the computer. The transaction table 1212 shows the transaction identifier of the transaction currently being processed, the transaction identifier of the transaction that directly corresponds to the parent in the hierarchical relationship, the state indicating whether the transaction is being executed or committed, and which process the transaction is processed by. Information on whether the transaction is being processed or on which other computer the transaction is being processed. Then, such a transaction management unit 121 performs a commit process to be described later with reference to these two tables.
[0029]
In this case, the transaction management unit 121 performs the commit process for the sub-transaction S according to the flow shown in FIG. At this time, the transaction management unit 121 simply records that the sub-transaction S is committed in the transaction table, and does not instruct the process 122 or process 123. At this time, an implementation method is also possible in which processing similar to that of the conventional two-phase commit is performed. Thereafter, when the processing of the top level transaction T is completed, the commit processing of the top level transaction is started. First, in the voting phase, VOTE-REQ (T) is sent to the process 122 that can execute the nested transaction involving T. Further, VOTE-REQ (S) is sent to the process 123 that cannot execute the nested transaction involved in the T sub-transaction S (steps S141 to S143).
[0030]
If a response of YES (T) is returned from the process 122 and YES (S) is returned from the process 123, the process proceeds to the next decision phase. In the decision phase, COMMIT (T) is sent to the process 122, and COMMIT (S) is sent to the process 123 that cannot execute the nested transaction involved in the transaction S. This completes the commit process for the entire transaction family (steps S144 to S146). In addition, when abort is determined in the voting phase of the top-level commit processing, the top-level transaction is aborted in a process that can execute the nested transaction, and the nested transaction is executed by executing the sub-transaction. The abort process of the corresponding transaction is also performed for the impossible process (steps S147 and S148).
[0031]
On the other hand, FIG. 7 is nested when the process 132 and the process 142 are executed on different computers 13 and 14 as shown in FIG. 4 and the transaction management units 131 and 141 exist in the respective computers 13 and 14. This shows transaction commit processing. In this case, as shown in FIGS. 1A and 1B, the transaction management units 131 and 141 manage two tables of the process tables 1311 and 1411 and the transaction tables 1312 and 1412 as in the case of the transaction management unit 121 described above. doing.
[0032]
Then, the transaction management unit 131 looks at the transaction table 1312 and knows that the transaction S has spread to the computer 14 and directly commits the transaction S to the process 142 that cannot execute the nested transaction processing on the computer 14. Instead, the communication means 15 informs the transaction manager 141 to perform the commit process of the top-level transaction T. In response to this, the transaction management unit 141 looks at the transaction table 1412 and the process table 1411 and performs the commit process of the transaction S to the process 142 that cannot execute the nested transaction.
[0033]
Note that the transaction management unit according to the present embodiment can be realized as an independent process, or can be realized by linking to a process that performs transaction processing in the form of a library or the like. In addition, the function of the transaction management unit can be incorporated into the operating system of the computer. In the present embodiment, the present invention is applied to the two-phase commit method. However, the present invention can be similarly applied to a commit processing method including a voting phase and a decision phase, such as a three-phase commit method. is there.
[0034]
(Second Embodiment)
In the first embodiment described above, the voting phase and the decision phase of the commit processing of a transaction processed by a process that cannot execute a nested transaction are both performed during the commit processing of the top-level transaction.
[0035]
Such sub-transaction voting phase processing may be performed at any point in time until the decision phase processing of the top-level transaction commit processing is started.
[0036]
Therefore, if processing is performed in the procedure of steps S171 to S179 shown in FIG. 8, for example, the transaction management unit 121 shown in FIG. 3 seems to manage the process 122 that can execute the nested transaction and the non-executable process 123. In this case, as shown in FIG. 9, the voting phase of the commit process for the process that cannot execute the nested transaction can be performed at the time of the commit process of the sub-transaction. It is possible to adopt an implementation method in which only phase processing is performed.
[0037]
In addition, a process 132 that can execute a nested transaction exists on the computer 13 shown in FIG. 4, and a process 142 that cannot execute a nested transaction exists on the computer 14, and both the computers 13 and 14 have a process 142. When the transaction managers 131 and 141 exist, as shown in FIG. 10, the transaction manager 131 sends the sub-transaction S to the transaction manager 141 on a different computer during the commit process of the sub-transaction S. Upon requesting the commit process, the transaction management unit 141 that has received the request can execute the voting phase of the commit process of the sub-transaction S with respect to the process 142 managed by itself.
[0038]
(Third embodiment)
In the second embodiment described above, the completion of the voting process of the commit process of the transaction S is awaited during the commit process of the sub-transaction S. This process is the decisive phase of the commit process of the top-level transaction. It suffices if the process is completed before the process is started.
[0039]
Therefore, if processing is performed according to the procedures of steps S201 to S208 in FIG. 11, for example, in the case of FIG. 3, the commit processing method as in FIG. 12 can be performed, while a plurality of processes as in FIG. When the process is divided into computers, the transaction management unit 131 notifies the transaction management unit 141 of the start of the voting phase of the transaction S commit process during the commit process of the sub-transaction S as shown in FIG. The unit 141 may notify the process 142 incapable of executing the nested transaction managed by itself of the start of the voting phase of the commit process.
[0040]
(Fourth embodiment)
In the second embodiment described above, the voting phase of the commit process for the transaction S is activated during the commit process of the sub-transaction S. This voting phase is activated as shown in FIG. It does not matter even after the processing is completed. This is the same even when the transaction is processed on a plurality of computers as shown in FIG. 4, and the commit processing method as shown in FIG. 15 can be implemented.
[0041]
For example, when a transaction extends to a plurality of computers as shown in FIG. 15, the sub-transaction S is piggybacked when a message is sent from the computer 13 to the computer 14 after the commit processing of the sub-transaction is completed. A request for starting the voting phase of the commit process can be sent from the transaction management unit 131 to the transaction management unit 142.
[0042]
(Fifth embodiment)
In this case, FIG. 16 shows a transaction including a transaction management unit 251 capable of managing a nested transaction and a computer 25 having a process 252, and a conventional transaction management unit 261 unable to manage a nested transaction and a computer 26 having a process 262. A processing device is shown. 17A and 17B show the configuration of the transaction management units 251 and 261, FIG. 18 shows the procedure of the commit process at this time, and FIG. 19 shows the commit process method, respectively.
[0043]
In this case, at the time of commit processing of the sub-transaction S, the transaction management unit 251 only records that the transaction has been committed and does nothing else. At this time, the transaction management unit 261 manages the sub-transaction S as still being executed. When committing the top-level transaction T, the transaction management unit 251 first sends VOTE-REQ (T) to the process 252 that can execute a nested transaction. Next, looking at the node table, it is found that the sub-transaction S has spread to a computer having a transaction management unit that cannot manage nested transactions, and sends VOTE-REQ (S) to the transaction management unit 261 (see FIG. 18 steps S271 to S273).
[0044]
The transaction manager 261 looks at the transaction table and finds that the transaction S is being executed in the process 262, and sends VOTE-REQ (S) to the process 262. When the process 262 completes the voting phase processing and returns YES (S) to the transaction management unit 2, the transaction management unit 261 returns YES (S) to the transaction management unit 251. When the transaction management unit 251 receives YES (T) from the process 252 and YES (S) from the transaction management unit 261, the transaction management unit 251 performs a process of determining the top level transaction. In the decision phase, the transaction management unit 251 sends COMMIT (T) to the process 252. Next, COMMIT (S) is sent to the transaction management unit 261. Receiving it, the transaction management unit 261 sends COMMIT (S) to the process 262 and completes the process of the decision phase (steps S274 to S276 in FIG. 18). If the transaction management unit 251 does not receive YES (T) from the process 252 and YES (S) from the transaction management unit 261, the transaction management unit 251 also performs abort processing for the corresponding transaction (steps S277 and S278).
[0045]
(Sixth embodiment)
In the fifth embodiment described above, the commit process of the transaction S spread to the computer 26 is all performed during the commit process of the top level transaction T. Of these, the voting phase process may be completed before the decision phase process of the commit process of the top-level transaction is started.
[0046]
Therefore, if the commit processing procedure shown in steps S291 to S299 in FIG. 20 and the commit processing method shown in FIG. 21 are used, the voting phase processing of the transaction S can be performed during the sub-transaction commit processing.
[0047]
(Seventh embodiment)
In the fifth embodiment described above, the commit process of the transaction S spread to the computer 26 is all performed during the commit process of the top level transaction T. Of these, the voting phase process may be completed before the decision phase process of the commit process of the top-level transaction is started. Therefore, even when the commit processing procedure shown in steps S311 to S318 in FIG. 22 and the commit processing method shown in FIG. 23 are used, it is possible to instruct the start of processing of the voting phase of transaction S during the commit processing of the sub-transaction. become.
[0048]
(Eighth embodiment)
In the fifth embodiment described above, the commit process of the transaction S spread to the computer 26 is all performed during the commit process of the top level transaction T. Of these, the voting phase process may be completed before the decision phase process of the commit process of the top-level transaction is started. Therefore, if the commit processing method shown in FIG. 24 is used, it is possible to instruct the start of the voting phase processing of the transaction S at an arbitrary time after the commit processing of the sub-transaction. The timing for starting the processing may be notified by piggybacking when some communication occurs from the computer 25 to the computer 26.
[0049]
In addition, this invention is not limited only to the said embodiment, In the range which does not change a summary, it can deform | transform suitably and can be implemented.
[0050]
【The invention's effect】
As described above, according to the transaction processing management method of the present invention, even when a process capable of executing a nested transaction and a non-executable process coexist, the nested transaction processing can be performed. For non-executable processes, those used for non-nested transaction processing can be used as they are.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration of a transaction management unit according to a first embodiment of this invention.
FIG. 2 is a diagram showing a configuration of a transaction management unit according to the first embodiment of this invention.
FIG. 3 is a block diagram showing an input transaction processing apparatus according to the first embodiment of the present invention.
FIG. 4 is a configuration diagram showing a distributed transaction processing apparatus according to the first embodiment of this invention.
FIG. 5 is a flowchart for explaining the operation of the first exemplary embodiment of the present invention;
FIG. 6 is a diagram for explaining commit processing in the first embodiment of the present invention;
FIG. 7 is a diagram for explaining commit processing in the first embodiment of the present invention;
FIG. 8 is a flowchart for explaining the operation of the second exemplary embodiment of the present invention;
FIG. 9 is a diagram for explaining commit processing in the second embodiment of the present invention;
FIG. 10 is a diagram for explaining commit processing in the second embodiment of the present invention;
FIG. 11 is a flowchart for explaining the operation of the third exemplary embodiment of the present invention;
FIG. 12 is a diagram for explaining commit processing in the third embodiment of the present invention;
FIG. 13 is a diagram for explaining commit processing in the third embodiment of the present invention;
FIG. 14 is a diagram for explaining commit processing in the fourth embodiment of the present invention;
FIG. 15 is a diagram for explaining commit processing according to the fourth embodiment of the present invention;
FIG. 16 is a configuration diagram showing a distributed transaction processing apparatus according to a fifth embodiment of the present invention;
FIG. 17 is a diagram showing a configuration of a transaction management unit according to the fifth embodiment of this invention;
FIG. 18 is a flowchart for explaining the operation of the fifth embodiment of the present invention;
FIG. 19 is a diagram for explaining commit processing in the fifth embodiment of the present invention;
FIG. 20 is a flowchart for explaining the operation of the sixth embodiment of the present invention;
FIG. 21 is a diagram for explaining commit processing in the sixth embodiment of the present invention;
FIG. 22 is a flowchart for explaining the operation of the seventh embodiment of the present invention;
FIG. 23 is a diagram for explaining commit processing in the seventh embodiment of the present invention;
FIG. 24 is a diagram for explaining commit processing in the eighth embodiment of the present invention;
FIG. 25 is a block diagram showing a conventional transaction processing apparatus.
FIG. 26 is a block diagram showing a conventional distributed transaction processing apparatus.
FIG. 27 is a block diagram showing another conventional transaction processing apparatus.
FIG. 28 is a block diagram showing another conventional distributed transaction processing apparatus.
FIG. 29 is a diagram for explaining commit processing of a conventional transaction processing apparatus.
FIG. 30 is a diagram for explaining an abort process of a conventional transaction processing apparatus.
FIG. 31 is a diagram for explaining commit processing of a conventional transaction processing apparatus;
FIG. 32 is a diagram showing the state of a transaction that is processed independently;
FIG. 33 is a diagram showing a configuration in which transactions are nested to have a hierarchy.
FIG. 34 is a diagram showing a configuration in which transactions are nested to have a hierarchy.
FIG. 35 shows a nested transaction
FIG. 36 is a block diagram showing a nested transaction processing apparatus.
FIG. 37 is a block diagram showing a distributed nested transaction processing device.
FIG. 38 is a diagram showing an example of a commit process of a nested transaction
FIG. 39 is a diagram illustrating an example of commit processing of a nested transaction
[Explanation of symbols]
121 ... Transaction management section
1211 ... Process table
1212 ... Transaction table
122, 123 ... Process
13, 14, 25, 26 ... computer
131, 141, 251 and 261 ... transaction management unit
132, 142, 252, 262 ... process

Claims (5)

A method for managing transaction processing in a transaction processing system including a process capable of executing a nested transaction and a process not capable of executing a nested transaction,
A sub-transaction of a nested transaction is executed by each of the process that can execute the nested transaction and the process that cannot execute the nested transaction,
Commit processing is performed for the sub-transaction executed by the process capable of executing the nested transaction,
Execute a top-level transaction of the nested transaction;
Commit processing of the executed top-level transaction,
A transaction process management method comprising: completing a commit process for a sub-transaction executed by a process incapable of executing a nested transaction together with completion of the commit process of the top-level transaction. Managing transaction processing according to claim 1, characterized in that the commit processing for the sub-transactions performed by the nested transaction infeasible process, in parallel with the commit process of the top-level transaction. Performing a voting phase of the commit process for the sub-transaction executed by the process that cannot execute the nested transaction in parallel with the commit process for the sub-transaction executed by the process that can execute the nested transaction;
Managing transaction processing according to claim 1, characterized in that the nested transaction infeasible decision phase commit processing for the sub-transactions performed by the process, in parallel with the commit process of the top-level transaction Method. The voting phase of the commit process for the sub-transaction executed by the process that cannot execute the nested transaction, the commit process for the sub-transaction executed by the process that can execute the nested transaction, and the execution of the top-level transaction of the nested transaction In parallel with
Managing transaction processing according to claim 1, characterized in that the nested transaction infeasible decision phase commit processing for the sub-transactions performed by the process, in parallel with the commit process of the top-level transaction Method. Performing a voting phase of the commit process for the sub-transaction executed by the process that cannot execute the nested transaction in parallel with the execution of the top-level transaction of the nested transaction;
Managing transaction processing according to claim 1, characterized in that the nested transaction infeasible decision phase commit processing for the sub-transactions performed by the process, in parallel with the commit process of the top-level transaction Method.

Images