System for flexible distributed processing and transaction processing suitable for nested transaction5778179Abstract A flexible distributed processing system capable of dealing with sophisticated conditions for selecting a server process. In the system, each of the services provided by all server processes is registered in the service manager in correspondence with an executability condition for judging whether each service is executed, such that the service manager selects one of the server processes which is providing the desired service indicated by the inquiry transmitted from the client process and which is judged to be executable according to the executability condition registered at the service manager, and the client process requests the desired service the selected one of the server processes. The system can utilize a transaction processing for a nested transaction in which a commit processing for the processes of the sub-transactions which are incapable of executing the nested transaction, is completed concurrently with a completion of the commit processing for the top level transaction. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
constA(int m, int d) {
if (1 <= m && m <= 49999) return(TRUE);
else return(FALSE);
______________________________________
In this fourth embodiment, in response to the inquiry made by the client process 1d, the service manager reads the appropriate executability judgement program from the file system 4 and judges the executability of each service according to this executability judgement program. For example, in response to the inquiry from the client process in a form of: lookup("Deposit", 39012, 5000); the executability judgement program takes a form of: constA(39012, 5000); which returns the answer "TRUE", so that the service manager can return a reply indicating that the server process 1c on the processor-A 1 is capable of executing the requested service to the client process 1d. Referring now to FIG. 23, a fifth embodiment of a distributed processing system according to the present invention will be described in detail. Here, those elements which are substantially equivalents to the corresponding elements in the first embodiment of FIG. 16 described above will be given the same reference numerals in the figures, and their descriptions will be omitted. This fifth embodiment differs from the first embodiment of FIG. 23 in that the database-A 1e and the database-B 2e are not provided on the processor-A 1 and the processor-B 2, and there is provided a common database 5 for storing the data for the account numbers 1 to 99999, with respect to the processor-A 1 and the processor-B 2, such that the server processes 1c and 2c provide the same services. In this case, each of the service managers 1a and 2a possesses the service management table as shown in FIG. 24 in which each entry comprises a processor name, a server name, a service name, and a judgement procedure, for all the executable services on each server process registered by the server processes 1c and 2c. Then, the service manager makes the selection of the appropriate server process capable of executing the service requested by the client process 1d according to the loading state of the server process or the processor on which the server process is present. Thus, in this fifth embodiment, when a plurality of server processes providing the same services are included, it becomes possible to distribute the load among these server processes by selecting the less loaded one of these server processes. As described in the first to fifth embodients above, according to the present invention, it becomes possible to realize a distributed processing system capable of making a selection of the appropriate server process according to more sophisticated conditions that cannot be accounted by the simple pattern matching procedure, by utilizing the executability judgement procedure or the executability judgement program assigned to each service in advance which can express the conditions on the arguments of the server process such as the account number, so as to realize the distribution of the loads or the functions over a plurality of processors according to such sophisticated conditions. Referring now to FIG. 25, a first embodiment of a transaction processing system according to the present invention, which can be utilized in the distributed processing system of the present invention described above, will be described in detail. This first embodiment concerns with a case of managing the nested transaction formed by a top level transaction T and its sub-transaction S, on a processor 12 having a transaction manager 121 capable of managing the nested transaction, a process-1 122 capable of executing the nested transaction, and a process-2 123 incapable of executing the nested transaction. In this case, as shown in FIG. 26, the transaction manager 121 has two tables of a process table 1211 and a transaction table 1212. The process table 1211 enlists process numbers of the processes to be executed in the transaction processing on this processor 12 along with hierarchy flags indicating whether each of the processes to be executed in the transaction processing on this processor 12 is capable of executing the nested transaction or not. On the other hand, the transaction table 1212 enlists a transaction identifier such as T or S for each transaction to be executed, the transaction identifier of a parent transaction of each transaction, a state of each transaction indicating whether each transaction is in execution or committed, and the process numbers of the processes to be executed in each transaction. Now, in this first embodiment, the transaction manager 121 carries out the commit processing by using these two tables according to the timing chart of FIG. 27 as follows. Namely, when the execution of the sub-transaction S is completed, the commit processing for the sub-transaction S is carried out by the transaction manager 121, only for the processes of the sub-transaction S which are capable of executing the nested transaction such as the process-1 122, while not carrying out the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction such as the process-2 123. At this point, the transaction manager 121 only records the commitment of the sub-transaction S in the transaction table 1212, without making any command with respect to the process-1 122 and the process-2 123, although it is also possible to carry out the operation in the usual two-phase commit protocol at this point. Then, after the execution of the top level transaction T is completed, the transaction manager 121 carries out the commit processing for the top level transaction T, along with the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction such as the process-2 123, according to the flow chart of FIG. 28 as follows. First, at the step S141, whether it is the top level transaction or not is determined. When it is not the top level transaction, the process is terminated. When it is the top level transaction, next at the step S142, a vote request VOTE-REQ(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 122. Then, next at the step S143, a vote request VOTE-REQ(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the processes which are related to any one of the sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the process-2 123. Then, next at the step S144, whether the replies YES(T) or YES(S) are received from all the processes to which the vote requests VOTE-REQ(T) and VOTE-REQ(S) have been transmitted or not is determined. When the replies YES(T) or YES(S) are received from all the processes to which the vote requests VOTE-REQ(T) and VOTE-REQ(S) have been transmitted, as shown in the timing chart of FIG. 27, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, first at the step S145, a commit request COMMIT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 122. Then, next at the step S146, a commit request COMMIT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the processes which are related to any one of the sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the process-2 123, and the process is terminated. On the other hand, when at least one reply NO(T) or NO(S) is received from any one of the processes to which the vote requests VOTE-REQ(T) and VOTE-REQ(S) have been transmitted, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, first at the step S147, an abort request ABORT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 122. Then, next at the step S148, an abort request ABORT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the processes which are related to any sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the process-2 123, and the process is terminated. In this manner, the commit processing for the entire transaction family can be completed. Now, the commit processing procedure similar to that of the first embodiment above is also applicable to a case of managing the nested transaction formed by a top level transaction T and its sub-transaction S on a configuration shown in FIG. 29, which includes: a processor 13 having a transaction manager 131 capable of managing the nested transaction and a process-1 132 capable of executing the nested transaction; and a processor 14 having a transaction manager 141 capable of managing the nested transaction and a process-2 142 incapable of executing the nested transaction; where the transaction managers 131 and 141 can communicate with each other through a communication connection 15. In this case, as shown in FIG. 30A, the transaction managers 131 has two tables of a process table 1311 and a transaction table 1312. The process table 1311 enlists process numbers of the processes to be executed in the transaction processing on the processor 13 along with hierarchy flags indicating whether each of the processes to be executed in the transaction processing on the processor 13 is capable of executing the nested transaction or not. On the other hand, the transaction table 1312 enlists a transaction identifier such as T or S for each transaction to be executed, the transaction identifier of a parent transaction of each transaction, a state of each transaction indicating whether each transaction is in execution or committed, the process numbers of the processes to be executed in each transaction, and the node numbers indicating which other processor is this transaction related to. Similarly, as shown in FIG. 30B, the transaction manager 141 has two tables of a process table 1411 and a transaction table 1412 in forms similar to those of the transaction manager 131. Now, in this case, the transaction manager 131 carries out the commit processing according to the timing chart of FIG. 31 as follows. Namely, when the execution of the sub-transaction S is completed, the commit processing for the sub-transaction S is carried out by the transaction manager 131, only for the processes of the sub-transaction S which are capable of executing the nested transaction such as the process-1 132, while not carrying out the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction such as the process-2 133. Then, after the execution of the top level transaction T is completed, the transaction manager 131 carries out the commit processing for the top level transaction T, along with the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction such as the process-2 142, according to the flow chart of FIG. 28 described above. Here, the transaction manager 131 can realize the fact that the sub-transaction S is also distributed to the processor 14 from the transaction table 1312, so that instead of carrying out the commit processing for the process-2 142 which is incapable of executing the nested transaction directly, the transaction manager 131 notifies the transaction manager 141 on the processor 14 to carry out the commit processing for the top level transaction T through the communication connection 15. In response, the transaction manager 141 carries out the commit processing for the process-2 142 which is incapable of executing the nested transaction, according to the process table 1411 and the transaction table 1412, and returns the result of this commit processing for the process-2 142 as the result of the commit processing for the top level transaction to the transaction manager 131 through the communication connection 15. It is to be noted that the commit processing procedure of the first embodiment described above is equally applicable to a case of realizing the transaction manager as an independent process and to a case of realizing the transaction manager as a library which is linked to a process for the transaction processing. It is also to be noted that the commit processing procedure of the first embodiment described above is also applicable to a commit processing protocol other than the two-phase commit protocol such as a three-phase commit protocol which also includes the vote phase and the decision phase. Referring now to FIGS. 32 and 33, a second embodiment of a transaction processing system according to the present invention, which can be utilized in the distributed processing system of the present invention described above, will be described in detail. This second embodiment also concerns with a case similar to that of the first embodiment described above, in which the nested transaction formed by a top level transaction T and its sub-transaction S is to be managed on the processor 12 shown in FIG. 25, in which the transaction manager 121 has the process table 1211 and the transaction table 1212 as shown in FIG. 26. Here, however, in this second embodiment, the transaction manager 121 carries out the commit processing according to the timing chart of FIG. 32 as follows. Namely, when the execution of the sub-transaction S is completed, the transaction manager 121 carries out the vote phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction, concurrently with the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction, while not carrying out the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction. Then, after the execution of the top level transaction T is completed, the transaction manager 121 carries out the commit processing for the top level transaction T, where the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is also carried out, concurrently with the decision phase of the commit processing for the top level transaction T, according to the flow chart of FIG. 33 as follows. First, at the step S171, whether it is the top level transaction or not is determined. Then, in a case it is the top level transaction, i.e., a case of the commit processing for the top level transaction T, next at the step S172, a vote request VOTE-REQ(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 122. Then, next at the step S173, whether the replies YES(T) are received from all the processes to which the vote requests VOTE-REQ(T) have been transmitted or not is determined. When the replies YES(T) are received from all the processes to which the vote requests VOTE-REQ(T) have been transmitted, as shown in the timing chart of FIG. 32, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, first at the step S174, a commit request COMMIT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 122. Then, next at the step S175, a commit request COMMIT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the processes which are related to any one of the sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the process-2 123, and the process is terminated. On the other hand, when at least one reply NO(T) is received from any one of the processes to which the vote requests VOTE-REQ(T) have been transmitted, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, at the step S176, an abort request ABORT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 122. Then, next at the step S177, an abort request ABORT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the processes which are related to any one of the sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the process-2 123, and the process is terminated. Meanwhile, when it is not the top level transaction at the step S171, i.e., a case of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction, next at the step S178, a vote request VOTE-REQ(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the processes which are related to any one of the sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the process-2 123, during with the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction. Then, next at the step S179, whether the replies YES(S) are received from all the processes to which the vote requests VOTE-REQ(S) have been transmitted or not is determined. When the replies YES(S) are received from all the processes to which the vote requests VOTE-REQ(S) have been transmitted, as shown in the timing chart of FIG. 32, the process is terminated. On the other hand, when at least one reply NO(S) is received from any one of the processes to which the vote requests VOTE-REQ(S) have been transmitted, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, at the step S180, an abort request ABORT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the processes which are related to any sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the process-2 123, and the process is terminated. In this manner, the commit processing for the entire transaction family can be completed. It is to be noted that this commit processing procedure of the second embodiment is equally valid as that of the first embodiment described above, because it suffices for the vote phase of the commit processing for the process of the sub-transaction S which are incapable of executing the nested transaction to be completed any time before the decision phase of the commit processing for the top level transaction T starts. Now, the commit processing procedure similar to that of the second embodiment above is also applicable to a case of managing the nested transaction formed by a top level transaction T and its sub-transaction S on a configuration shown in FIG. 29. In this case, the transaction manager 131 carries out the commit processing according to the timing chart of FIG. 34 as follows. Namely, when the execution of the sub-transaction S is completed, the transaction manager 131 carries out the vote phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction through the transaction manager 141, concurrently with the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction, while not carrying out the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction. Then, after the execution of the top level transaction T is completed, the transaction manager 131 carries out the commit processing for the top level transaction T, where the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is also carried out through the transaction manager 141, concurrently with the decision phase of the commit processing for the top level transaction T, according to the flow chart of FIG. 33 described above. Here, the transaction manager 131 can realize the fact that the sub-transaction S is also distributed to the processor 14 from the transaction table 1312. Consequently, at a timing of the commit processing for the sub-transaction S, instead of carrying out the commit processing for the process-2 142 which is incapable of executing the nested transaction directly, the transaction manager 131 notifies the transaction manager 141 on the processor 14 to carry out the vote phase of the commit processing for the process 142 of the sub-transaction S which is incapable of executing the nested transaction, through the communication connection 15. In response, the transaction manager 141 carries out the vote phase of the commit processing for the process-2 142 which is incapable of executing the nested transaction, according to the process table 1411 and the transaction table 1412, and returns the result of this vote phase of the commit processing for the process-2 142 to the transaction manager 131 through the communication connection 15. Then, at a timing of the commit processing for the top level transaction T, instead of carrying out the decision phase of the commit processing for the process-2 142 which is incapable of executing the nested transaction directly, the transaction manager 131 notifies the transaction manager 141 on the processor 14 to carry out the commit processing for the top level transaction T through the communication connection 15. In response, the transaction manager 141 carries out the commit processing for the process-2 142 which is incapable of executing the nested transaction, according to the process table 1411 and the transaction table 1412. Referring now to FIGS. 35 and 36, a third embodiment of a transaction processing system according to the present invention, which can be utilized in the distributed processing system of the present invention described above, will be described in detail. This third embodiment also concerns with a case similar to that of the first embodiment described above, in which the nested transaction formed by a top level transaction T and its sub-transaction S is to be managed on the processor 12 shown in FIG. 25, in which the transaction manager 121 has the process table 1211 and the transaction table 1212 as shown in FIG. 26. Here, however, in this third embodiment, the transaction manager 121 carries out the commit processing according to the timing chart of FIG. 35 as follows. Namely, when the execution of the sub-transaction S is completed, the transaction manager 121 carries out the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction. At the same time, the transaction manager 121 transmits the vote request VOTE-REQ(S) to the processes of the sub-transaction S which are incapable of executing the nested transaction. In other words, a first part of the vote phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is carried out concurrently with the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction. Then, during the execution of the top level transaction T, the reply for the VOTE-REQ(S) is returned from the processes of the sub-transaction S which are incapable of executing the nested transaction to the transaction manager 121. Then, after the execution of the top level transaction T is completed, the transaction manager 121 carries out the commit processing for the top level transaction T, where the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is carried out concurrently with the decision phase of the commit processing for the top level transaction T, according to the flow chart of FIG. 36 as follows. First, at the step S201, whether it is the top level transaction or not is determined. Then, in a case it is the top level transaction, i.e., a case of the commit processing for the top level transaction T, next at the step S202, a vote request VOTE-REQ(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 122. Then, next at the step S203, whether the replies YES(T) or YES(S) are received from all the processes to which the vote requests VOTE-REQ(T) and VOTE-REQ(S) have been transmitted or not is determined. When the replies YES(T) or YES(S) are received from all the processes to which the vote requests VOTE-REQ(T) and VOTE-REQ(S) have been transmitted, as shown in the timing chart of FIG. 35, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, first at the step S204, a commit request COMMIT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 122. Then, next at the step S205, a commit request COMMIT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the processes which are related to any one of the sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the process-2 123, and the process is terminated. On the other hand, when at least one reply NO(T) or NO(S) is received from any one of the processes to which the vote requests VOTE-REQ(T) and VOTE-REQ(S) have been transmitted, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, first at the step S207, an abort request ABORT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 122. Then, next at the step S208, an abort request ABORT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the processes which are related to any sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the process-2 123, and the process is terminated. Meanwhile, when it is not the top level transaction at the step S201, i.e., a case of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction, next at the step S206, a vote request VOTE-REQ(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the processes which are related to any one of the sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the process-2 123, and the process is terminated. In this manner, the commit processing for the entire transaction family can be completed. It is to be noted that this commit processing procedure of the third embodiment is equally valid as that of the first embodiment described above, because it suffices for the vote phase of the commit processing for the process of the sub-transaction S which are incapable of executing the nested transaction to be completed any time before the decision phase of the commit processing for the top level transaction T starts. Now, the commit processing procedure similar to that of the third embodiment above is also applicable to a case of managing the nested transaction formed by a top level transaction T and its sub-transaction S on a configuration shown in FIG. 29. In this case, the transaction manager 131 carries out the commit processing according to the timing chart of FIG. 37 as follows. Namely, when the execution of the sub-transaction S is completed, the transaction manager 131 carries out the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction. At the same time, the transaction manager 131 transmits the vote request VOTE-REQ(S) to the processes of the sub-transaction S which are incapable of executing the nested transaction, through the transaction manager 141. In other words, a first part of the vote phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is carried out concurrently with the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction. Then, during the execution of the top level transaction T, the reply for the VOTE-REQ(S) is returned from the processes of the sub-transaction S which are incapable of executing the nested transaction to the transaction manager 131 through the transaction manager 141. Then, after the execution of the top level transaction T is completed, the transaction manager 131 carries out the commit processing for the top level transaction T, where the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is carried out through the transaction manager 141, concurrently with the decision phase of the commit processing for the top level transaction T, according to the flow chart of FIG. 36 described above. Here, the transaction manager 131 can realize the fact that the sub-transaction S is also distributed to the processor 14 from the transaction table 1312. Consequently, at a timing of the commit processing for the sub-transaction S, instead of carrying out the commit processing for the process-2 142 which is incapable of executing the nested transaction directly, the transaction manager 131 notifies the transaction manager 141 on the processor 14 to carry out the vote phase of the commit processing for the process 142 of the sub-transaction S which is incapable of executing the nested transaction, through the communication connection 15. In response, the transaction manager 141 carries out the vote phase of the commit processing for the process-2 142 which is incapable of executing the nested transaction, according to the process table 1411 and the transaction table 1412, and then returns the result of this vote phase of the commit processing for the process-2 142 to the transaction manager 131 through the communication connection 15 during the execution of the top level transaction T. Then, at a timing of the commit processing for the top level transaction T, instead of carrying out the decision phase of the commit processing for the process-2 142 which is incapable of executing the nested transaction directly, the transaction manager 131 notifies the transaction manager 141 on the processor 14 to carry out the commit processing for the top level transaction T through the communication connection 15. In response, the transaction manager 141 carries out the commit processing for the process-2 142 which is incapable of executing the nested transaction, according to the process table 1411 and the transaction table 1412. Referring now to FIGS. 38 and 39, a fourth embodiment of a transaction processing system according to the present invention, which can be utilized in the distributed processing system of the present invention described above, will be described in detail. This fourth embodiment also concerns with a case similar to that of the first embodiment described above, in which the nested transaction formed by a top level transaction T and its sub-transaction S is to be managed on the processor 12 shown in FIG. 25, in which the transaction manager 121 has the process table 1211 and the transaction table 1212 as shown in FIG. 26. Here, however, in this fourth embodiment, the transaction manager 121 carries out the commit processing according to the timing chart of FIG. 38 as follows. Namely, when the execution of the sub-transaction S is completed, the transaction manager 121 carries out the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction, while not carrying out the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction. Then, during the execution of the top level transaction T, the transaction manager 121 carries out the vote phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction. Then, after the execution of the top level transaction T is completed, the transaction manager 121 carries out the commit processing for the top level transaction T, where the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is also carried out, concurrently with the decision phase of the commit processing for the top level transaction T, just as in the third embodiment described above. It is to be noted that this commit processing procedure of the fourth embodiment is equally valid as that of the first embodiment described above, because it suffices for the vote phase of the commit processing for the process of the sub-transaction S which are incapable of executing the nested transaction to be completed any time before the decision phase of the commit processing for the top level transaction T starts. Now, the commit processing procedure similar to that of the fourth embodiment above is also applicable to a case of managing the nested transaction formed by a top level transaction T and its sub-transaction S on a configuration shown in FIG. 29. In this case, the transaction manager 131 carries out the commit processing according to the timing chart of FIG. 39 as follows. Namely, when the execution of the sub-transaction S is completed, the transaction manager 131 carries out the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction, while not carrying out the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction. Then, during the execution of the top level transaction T, the transaction manager 131 carries out the vote phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction, through the transaction manager 141. Then, after the execution of the top level transaction T is completed, the transaction manager 131 carries out the commit processing for the top level transaction T, where the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is also carried out through the transaction manager 141, concurrently with the decision phase of the commit processing for the top level transaction T, just as in the third embodiment described above. Here, the transaction manager 131 can realize the fact that the sub-transaction S is also distributed to the processor 14 from the transaction table 1312. Consequently, at a timing of the execution of the top level transaction T, instead of carrying out the commit processing for the process-2 142 which is incapable of executing the nested transaction directly, the transaction manager 131 notifies the transaction manager 141 on the processor 14 to carry out the vote phase of the commit processing for the process 142 of the sub-transaction S which is incapable of executing the nested transaction, through the communication connection 15. In response, the transaction manager 141 carries out the vote phase of the commit processing for the process-2 142 which is incapable of executing the nested transaction, according to the process table 1411 and the transaction table 1412, and returns the result of the vote phase of the commit processing for the process-2 142 to the transaction manager 131 through the communication connection 15 during the execution of the top level transaction T. Then, at a timing of the commit processing for the top level transaction T, instead of carrying out the decision phase of the commit processing for the process-2 142 which is incapable of executing the nested transaction directly, the transaction manager 131 notifies the transaction manager 141 on the processor 14 to carry out the commit processing for the top level transaction T through the communication connection 15. In response, the transaction manager 141 carries out the commit processing for the process-2 142 which is incapable of executing the nested transaction, according to the process table 1411 and the transaction table 1412. As described, in the first to fourth embodiments described above, the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is postponed until a timing for the commit processing for the top level transaction T. Moreover, at a timing for the commit processing for the top level transaction T, the commit for the entire transaction family is determined according to both of the commit for the top level transaction T as well as the commit for the processes of the sub-transaction S which are incapable of executing the nested transaction. As a result, it is possible in these first to fourth embodiments to carry out the commit processing for maintaining the atomicity, consistency, isolation, and durability in the entire transaction family, without requiring the rewriting of the program of the process which are incapable of executing the nested transaction. Consequently, according to these first to fourth embodiments, it becomes possible to provide a transaction processing system suitable for dealing with a nested transaction, which is compatible with already existing process incapable of dealing with a nested transaction. Referring now to FIG. 40, a fifth embodiment of a transaction processing system according to the present invention, which can be utilized in the distributed processing system of the present invention described above, will be described in detail. This fifth embodiment concerns with a case of managing the nested transaction formed by a top level transaction T and its sub-transaction S on a configuration shown in FIG. 40, which includes: a processor 25 having a transaction manager 251 capable of managing the nested transaction and a process-1 252 capable of executing the nested transaction; and a processor 26 having a transaction manager 261 incapable of managing the nested transaction and a process-2 262 incapable of executing the nested transaction; where the transaction managers 251 and 261 can communicate with each other through a communication connection 27. In this case, as shown in FIG. 41A, the transaction managers 251 has three tables of a process table 2511, a transaction table 2512, and a node table 2513. The process table 2511 enlists process numbers of the processes to be executed in the transaction processing on the processor 25 along with hierarchy flags indicating whether each of the processes to be executed in the transaction processing on the processor 25 is capable of executing the nested transaction or not. The transaction table 2512 enlists a transaction identifier such as T or S for each transaction to be executed, the transaction identifier of a parent transaction of each transaction, a state of each transaction indicating whether each transaction is in execution or committed, the process numbers of the processes to be executed in each transaction, and the node numbers indicating which other processor is this transaction related to. The node table 2513 enlists node numbers of the nodes to be used on the processor 25 along with hierarchy flags indicating whether each of the nodes to be used on the processor 25 is capable of executing the nested transaction or not. On the other hand, as shown in FIG. 41B, the transaction manager 261 only has a transaction table 2612 in forms similar to the transaction table 2512 of the transaction manager 251. Now, in this case, the transaction manager 251 carries out the commit processing according to the timing chart of FIG. 42 as follows. Namely, when the execution of the sub-transaction S is completed, the commit processing for the sub-transaction S is carried out by the transaction manager 131, only for the processes of the sub-transaction S which are capable of executing the nested transaction such as the process-1 252, while not carrying out the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction such as the process-2 262. At this point, the transaction manager 251 only records the commitment of the sub-transaction S in the transaction table 2512, without making any command with respect to the process-1 252 and the process-2 262, while the transaction manager 261 still manages the sub-transaction S as being in the execution. Then, after the execution of the top level transaction T is completed, the transaction manager 251 carries out the commit processing for the top level transaction T, along with the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction such as the process-2 262 through the transaction manager 261, according to the flow chart of FIG. 43 as follows. First, at the step S271, whether it is the top level transaction or not is determined. When it is not the top level transaction, the process is terminated. When it is the top level transaction, next at the step S272, a vote request VOTE-REQ(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 252. Then, next at the step S273, as it is indicated in the node table 2513 that the sub-transaction S is distributed over the processor 26 having the transaction manager 261 incapable of managing the nested transaction, the transaction manager 251 transmits a vote request VOTE-REQ(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction to all the transaction managers of the sub-transaction S which are related to any one of the sub-transaction S of the top level transaction T and incapable of managing the nested transaction, which in this case include the transaction manager 261. In response, the transaction manager 261 transmits the vote request VOTE-REQ(S) to the processes of the sub-transaction S which are incapable of executing the nested transaction such as the process-2 262, as it is indicated in the transaction table 2612 that the sub-transaction S is executed in the process-2 262. When the process-2 262 returns the reply YES(S) to the transaction manage 261, the transaction manager 261 in turn returns the reply YES(S) to the transaction manager 251. Then, next at the step S274, whether the replies YES(T) or YES(S) are received for all of the transmitted vote requests VOTE-REQ(T) and VOTE-REQ(S) or not is determined. When the replies YES(T) or YES(S) are received for all of the transmitted vote requests VOTE-REQ(T) and VOTE-REQ(S), as shown in the timing chart of FIG. 42, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, first at the step S275, a commit request COMMIT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 252. Then, next at the step S276, a commit request COMMIT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the transaction managers of the sub-transaction S which are related to any one of the sub-transaction S of the top level transaction T and incapable of managing the nested transaction, which in this case include the transaction manager 261, and the process is terminated. On the other hand, when at least one reply NO(T) or NO(S) is received for any one of the transmitted vote requests VOTE-REQ(T) and VOTE-REQ(S), the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, first at the step S277, an abort request ABORT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 252. Then, next at the step S278, an abort request ABORT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the transaction managers of the sub-transaction S which are related to any sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the transaction manager 261, and the process is terminated. In this manner, the commit processing for the entire transaction family can be completed. Referring now to FIGS. 44 and 45, a sixth embodiment of a transaction processing system according to the present invention, which can be utilized in the distributed processing system of the present invention described above, will be described in detail. This sixth embodiment also concerns with a case similar to that of the fifth embodiment described above, in which the nested transaction formed by a top level transaction T and its sub-transaction S is to be managed on the configuration shown in FIG. 40, in which the transaction manager 251 capable of managing the nested transaction has the process table 2511, the transaction table 2512, and the node table 2513 as shown in FIG. 41A, while the transaction manager 261 incapable of managing the nested transaction only has the transaction table 2612. Here, however, in this sixth embodiment, the transaction manager 251 carries out the commit processing according to the timing chart of FIG. 44 as follows. Namely, when the execution of the sub-transaction S is completed, the transaction manager 251 carries out the vote phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction through the transaction manager 261, concurrently with the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction, while not carrying out the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction. Then, after the execution of the top level transaction T is completed, the transaction manager 251 carries out the commit processing for the top level transaction T, where the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is also carried out through the transaction manager 261, concurrently with the decision phase of the commit processing for the top level transaction T, according to the flow chart of FIG. 45. First, at the step S291, whether it is the top level transaction or not is determined. Then, in a case it is the top level transaction, i.e., a case of the commit processing for the top level transaction T, next at the step S292, a vote request VOTE-REQ(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 252. Then, next at the step S293, whether the replies YES(T) are received from all the processes to which the vote requests VOTE-REQ(T) have been transmitted or not is determined. When the replies YES(T) are received from all the processes to which the vote requests VOTE-REQ(T) have been transmitted, as shown in the timing chart of FIG. 44, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, first at the step S294, a commit request COMMIT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 252. Then, next at the step S295, a commit request COMMIT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the transaction managers of the sub-transaction S which are related to any one of the sub-transaction S of the top level transaction T and incapable of managing the nested transaction, which in this case include the transaction manager 261, and the process is terminated. On the other hand, when at least one reply NO(T) is received from any one of the processes to which the vote requests VOTE-REQ(T) have been transmitted, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, at the step S296, an abort request ABORT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 122. Then, next at the step S297, an abort request ABORT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the transaction managers of the sub-transaction S which are related to any one of the sub-transaction S of the top level transaction T and incapable of managing the nested transaction, which in this case include the transaction manager 261, and the process is terminated. Meanwhile, when it is not the top level transaction at the step S291, i.e., a case of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction, next at the step S298, a vote request VOTE-REQ(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the transaction managers of the sub-transaction S which are related to any one of the sub-transaction S of the top level transaction T and incapable of managing the nested transaction, which in this case include the transaction manager 261. Then, next at the step S299, whether the replies YES(S) are received from all the transaction managers to which the vote requests VOTE-REQ(S) have been transmitted or not is determined. When the replies YES(S) are received from all the transaction managers to which the vote requests VOTE-REQ(S) have been transmitted, as shown in the timing chart of FIG. 44, the process is terminated. On the other hand, when at least one reply NO(S) is received from any one of the transaction managers to which the vote requests VOTE-REQ(S) have been transmitted, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, at the step S300, an abort request ABORT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the transaction managers of the sub-transaction S which are related to any sub-transaction S of the top level transaction T and incapable of managing the nested transaction, which in this case include the transaction manager 261, and the process is terminated. In this manner, the commit processing for the entire transaction family can be completed. It is to be noted that this commit processing procedure of the sixth embodiment is equally valid as that of the fifth embodiment described above, because it suffices for the vote phase of the commit processing for the process of the sub-transaction S which are incapable of executing the nested transaction to be completed any time before the decision phase of the commit processing for the top level transaction T starts. Referring now to FIGS. 46 and 47, a seventh embodiment of a transaction processing system according to the present invention, which can be utilized in the distributed processing system of the present invention described above, will be described in detail. This seventh embodiment also concerns with a case similar to that of the fifth embodiment described above, in which the nested transaction formed by a top level transaction T and its sub-transaction S is to be managed on the configuration shown in FIG. 40, in which the transaction manager 251 capable of managing the nested transaction has the process table 2511, the transaction table 2512, and the node table 2513 as shown in FIG. 41A, while the transaction manager 261 incapable of managing the nested transaction only has the transaction table 2612. Here, however, in this seventh embodiment, the transaction manager 251 carries out the commit processing, according to the timing chart of FIG. 46 as follows. Namely, when the execution of the sub-transaction S is completed, the transaction manager 251 carries out the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction. At the same time, the transaction manager 251 transmits the vote request VOTE-REQ(S) to the transaction manager 261 incapable of executing the nested transaction. In other words, a first part of the vote phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is carried out concurrently with the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction. Then, during the execution of the top level transaction T, the reply for the VOTE-REQ(S) is returned from the processes of the sub-transaction S which are incapable of executing the nested transaction to the transaction manager 251 through the transaction manager 261. Then, after the execution of the top level transaction T is completed, the transaction manager 251 carries out the commit processing for the top level transaction T, where the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is carried out concurrently with the decision phase of the commit processing for the top level transaction T, according to the flow chart of FIG. 47. First, at the step S311, whether it is the top level transaction or not is determined. Then, in a case it is the top level transaction, i.e., a case of the commit processing for the top level transaction T, next at the step S312, a vote request VOTE-REQ(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 252. Then, next at the step S313, whether the replies YES(T) or YES(S) are received for all of the transmitted vote requests VOTE-REQ(T) and VOTE-REQ(S) or not is determined. When the replies YES(T) or YES(S) are received for all of the transmitted vote requests VOTE-REQ(T) and VOTE-REQ(S), as shown in the timing chart of FIG. 46, the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, first at the step S314, a commit request COMMIT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 252. Then, next at the step S315, a commit request COMMIT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the transaction managers of the sub-transaction S which are related to any one of the sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the transaction manager 261, and the process is terminated. On the other hand, when at least one reply NO(T) or NO(S) is received for any one of the transmitted vote requests VOTE-REQ(T) and VOTE-REQ(S), the vote phase is finished and the commit processing proceeds to the following decision phase next. Namely, in this case, in the decision phase, first at the step S317, an abort request ABORT(T) for the top level transaction T is transmitted to all the processes which are related to the top level transaction T and capable of executing the nested transaction, which in this case include the process-1 252. Then, next at the step S318, an abort request ABORT(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the transaction managers of the sub-transaction S which are related to any sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the transaction manager 261, and the process is terminated. Meanwhile, when it is not the top level transaction at the step S311, i.e., a case of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction, next at the step S316, a vote request VOTE-REQ(S) for the processes of the sub-transaction S which are incapable of executing the nested transaction is transmitted to all the transaction managers of the sub-transaction S which are related to any one of the sub-transaction S of the top level transaction T and incapable of executing the nested transaction, which in this case include the transaction manager 261, and the process is terminated. In this manner, the commit processing for the entire transaction family can be completed. It is to be noted that this commit processing procedure of the seventh embodiment is equally valid as that of the fifth embodiment described above, because it suffices for the vote phase of the commit processing for the process of the sub-transaction S which are incapable of executing the nested transaction to be completed any time before the decision phase of the commit processing for the top level transaction T starts. Referring now to FIG. 48, an eighth embodiment of a transaction processing system according to the present invention, which can be utilized in the distributed processing system of the present invention described above, will be described in detail. This eighth embodiment also concerns with a case similar to that of the fifth embodiment described above, in which the nested transaction formed by a top level transaction T and its sub-transaction S is to be managed on the configuration shown in FIG. 40, in which the transaction manager 251 capable of managing the nested transaction has the process table 2511, the transaction table 2512, and the node table 2513 as shown in FIG. 41A, while the transaction manager 261 incapable of managing the nested transaction only has the transaction table 2612. Here, however, in this eighth embodiment, the transaction manager 251 carries out the commit processing, according to the timing chart of FIG. 48 as follows. Namely, when the execution of the sub-transaction S is completed, the transaction manager 251 carries out the commit processing for the processes of the sub-transaction S which are capable of executing the nested transaction, while not carrying out the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction. Then, during the execution of the top level transaction T, the transaction manager 251 carries out the vote phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction, through the transaction manager 261. Then, after the execution of the top level transaction T is completed, the transaction manager 251 carries out the commit processing for the top level transaction T, where the decision phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction is also carried out through the transaction manager 261, concurrently with the decision phase of the commit processing for the top level transaction T, just as in the seventh embodiment described above. It is to be noted that this commit processing procedure of the eighth embodiment is equally valid as that of the fifth embodiment described above, because it suffices for the vote phase of the commit processing for the processes of the sub-transaction S which are incapable of executing the nested transaction to be completed any time before the decision phase of the commit processing for the top level transaction T starts. As described, according to the fifth to the eighth embodiments described above, it becomes possible to provide a transaction processing system suitable for dealing with a nested transaction, which is compatible with already existing transaction manager and process incapable of dealing with a nested transaction. Here, it is to be noted that the transaction processing system according to the present invention as described above may be utilized on its own right, independently from the distributed processing system of the present invention described above. It is also to be noted that, besides those already mentioned above, many modifications and variations of the above embodiments may be made without departing from the novel and advantageous features of the present invention. Accordingly, all such modifications and variations are intended to be included within the scope of the appended claims.
|
Same subclass | ||||||||||