WO2006057061A1 - 分散トランザクション処理方法、装置、及びプログラム - Google Patents

分散トランザクション処理方法、装置、及びプログラム Download PDF

Info

Publication number
WO2006057061A1
WO2006057061A1 PCT/JP2004/017733 JP2004017733W WO2006057061A1 WO 2006057061 A1 WO2006057061 A1 WO 2006057061A1 JP 2004017733 W JP2004017733 W JP 2004017733W WO 2006057061 A1 WO2006057061 A1 WO 2006057061A1
Authority
WO
WIPO (PCT)
Prior art keywords
processing
commit
transaction
failure
response
Prior art date
Application number
PCT/JP2004/017733
Other languages
English (en)
French (fr)
Inventor
Takayuki Tsunakawa
Naohiro Ito
Original Assignee
Fujitsu Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Limited filed Critical Fujitsu Limited
Priority to JP2006546521A priority Critical patent/JP4500318B2/ja
Priority to PCT/JP2004/017733 priority patent/WO2006057061A1/ja
Publication of WO2006057061A1 publication Critical patent/WO2006057061A1/ja
Priority to US11/807,334 priority patent/US7836338B2/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/466Transaction processing

Definitions

  • the present invention relates to a distributed transaction processing program and distributed transaction for instructing distributed processing of transactions accepted by application processing to a plurality of processing devices that always perform commit processing in response to a commit processing request other than the failure of the device itself.
  • the present invention relates to a distributed transaction processing program, a distributed transaction processing method, and a distributed transaction processing device capable of performing commit processing at high speed and reducing the burden of introduction and operation. is there.
  • Non-Patent Document 1 "Let's challenge distributed transactions!”, [Search October 12, 2004], Internet URL: HYPERLINK
  • the present invention has been made in view of the above, and is a distributed transaction processing program, a distributed transaction processing method, and a distributed transaction capable of performing commit processing at high speed and reducing the burden of introduction 'operation'
  • the purpose is to provide a processing device.
  • the distributed transaction processing program according to the invention of claim 1 always responds by performing a commit process on a commit process request except for a failure of the apparatus itself.
  • the commit response procedure responds to the application with a successful commit, and the commit process requested by the commit request procedure.
  • a recovery instruction procedure for instructing the failure processing apparatus is executed by a computer.
  • a commit process is requested from a plurality of processing devices in response to a commit request from an application, and any processing device power is also responded to the requested commit process.
  • a failure processing device recovers its failure power, it is a powerful processing device that cannot respond to the requested commit processing due to a failure. Since it was configured to instruct the failure processing unit based on the processing result of other processing units based on the processing result of other processing units, which is a powerful transaction that has not been responded to, the database is executed by one-phase commit. The consistency between them can be maintained.
  • the recovery instruction procedure is a recovery determination procedure for determining whether or not the failure processing device has recovered.
  • the processing result of the unresolved transaction of the failure processing device is inquired to another processing device, and based on the inquiry result, It is characterized by causing a computer to execute a processing device recovery processing procedure for requesting a processing for an unresolved transaction from a fault processing device.
  • the processing result of the unresolved transaction of the failure processing device is In other words, it is configured so that the other processing device is inquired, and based on the inquiry result, the processing of the unresolved transaction is requested to the failure processing device, so only the transaction log is managed by the processing device. Therefore, the transaction log management by the distributed transaction processing program can be made unnecessary.
  • the recovery determination procedure is performed by periodically checking the connection with the failure processing device. It is characterized by determining whether or not the failure processing apparatus has been restored.
  • the distributed transaction processing program according to the invention of claim 4 is an unresolved transaction program for the processing device in the invention of claim 1, 2 or 3 upon recovery from the failure of the own device.
  • Unresolved transaction that inquires other processing devices about the processing result of the unresolved transaction that has been answered
  • a request is made to the processing device that responded to the unresolved query for the processing for the unresolved transaction.
  • the device recovery processing procedure The computer is executed.
  • an unresolved query for querying an unresolved transaction is made to the processing device when the failure power of the own device is restored, and the processing device power is obtained for the unresolved query Ask the other processing device about the processing result of the returned unresolved transaction !, execute the matching processing result query !, and process the unresolved transaction for the unresolved query based on the response result to the processing result query. Since the processing device that responded to the outstanding transaction is requested, the computer that executes the distributed transaction processing program will remain after the recovery even if it fails after requesting commit processing to some of the processing devices. Commit processing can be performed correctly.
  • the distributed transaction processing program according to the invention of claim 5 is the invention according to claim 1, wherein the commit request procedure is performed when a request for commit processing is not accepted by any processing device. It returns a commit failure response to the application.
  • the distributed transaction processing program according to the invention of claim 6 is the processing device according to claim 1, wherein the commit response procedure is a deviation from the commit processing requested by the commit request procedure. If neither response nor response is possible, the commit response is unknown to the application.
  • the distributed transaction processing method according to the invention of claim 7 includes a plurality of processing devices that always respond by performing commit processing in response to a commit processing request, except for a failure of the device itself.
  • the commit response process responds to the application with a successful commit, and the commit process requested by the commit request process.
  • failure processing device which is a powerful processing device that cannot respond due to a failure, also recovers its failure power
  • other processing is performed for processing an unresolved transaction that is a powerful transaction that does not respond. Instruct the failure processing device based on the processing result of the device And the former instruction process, that it contained a feature.
  • a commit process is requested to a plurality of processing devices in response to a commit request from an application, and any processing device power responds to the requested commit processing.
  • a failure processing device recovers its failure power, it is a powerful processing device that cannot respond to the requested commit processing due to a failure. Since it was configured to instruct the failure processing unit based on the processing result of other processing units based on the processing result of other processing units, which is a powerful transaction that has not been responded to, the database is executed by one-phase commit. The consistency between them can be maintained.
  • the distributed transaction processing device is configured to process transactions that have received application power to a plurality of processing devices that always respond by performing commit processing in response to a commit processing request other than the failure of the device itself.
  • a distributed transaction processing device for instructing distributed processing wherein a commit request means for requesting commit processing to a plurality of processing devices in response to a request for committing the application power, and a commit process requested by the commit request means If there is a response from any of the processing devices, the commit response means responds to the application with the success of the commit, and the commit processing requested by the commit request means returns a response due to a failure.
  • a faulty processing device a powerful processing device that could not be performed, recovered its fault power. When the process forming the other processing apparatus for processing unresolved transaction is the response is performed such ChikaraTsutato Ranzakushiyon And recovery instruction means for instructing the failure processing apparatus based on the results.
  • a commit process is requested to a plurality of processing devices in response to a commit request from an application, and any processing device power responds to the requested commit process.
  • a failure processing device recovers its failure power, it is a powerful processing device that cannot respond to the requested commit processing due to a failure. Since it was configured to instruct the failure processing unit based on the processing result of other processing units based on the processing result of other processing units, which is a powerful transaction that has not been responded to, the database is executed by one-phase commit. The consistency between them can be maintained.
  • a distributed transaction processing device includes a plurality of processing devices that perform distributed processing of a single transaction, and receives a transaction processing request from an application and requests distributed processing from the plurality of processing devices.
  • a distributed transaction processing device configured to have a transaction management device for executing the request, wherein the transaction management device is configured to request commit processing from a plurality of processing devices in response to the request for committing the application power; Commit response means that responds to the application with a successful commit when there is any response to the commit process requested by the request means, and the commit process requested by the commit request means To respond to failure
  • a failure processing device which is a powerful processing device that cannot be used, recovers its fault power
  • the processing result of another processing device is determined by processing an unresolved transaction that is a powerful transaction for which the response has not been made.
  • Recovery instruction means for instructing the failure processing apparatus on the basis of the failure processing apparatus, and the processing apparatus always performs commit processing for a commit processing request from the transaction management apparatus except for a failure of the apparatus itself.
  • Commit processing means that can respond to the transaction management device and recovery processing means for processing the unresolved transaction based on an instruction from the transaction management device when the failure power is also restored. It is characterized by that.
  • the transaction management device requests commit processing from a plurality of processing devices in response to a commit request from the application, and performs the requested commit processing.
  • This is a powerful processor that cannot respond to the requested commit process due to a failure, and responds to a successful commit to the application when there is a response.
  • the failure processing device recovers its fault power, the failure processing device is instructed to process the unresolved transaction, which is a transaction for which no response has been made, based on the processing result of the other processing device.
  • it is possible to respond to the transaction management device by always performing commit processing in response to the commit processing request from the transaction management device, and based on the instruction of the transaction management device power when the failure power is recovered.
  • the distributed transaction processing method according to the invention of claim 10 accepts transaction processing requests from an application and a plurality of processing devices that perform distributed processing of a single transaction.
  • a transaction processing apparatus configured to request distributed processing from the processing apparatus, wherein the transaction management apparatus commits to a plurality of processing apparatuses in response to a commit request from the application.
  • a commit request step for requesting processing a commit processing step for responding to the transaction management device by always performing a commit processing on the commit processing request from the transaction management device unless the processing device itself is faulty
  • Request for commit In response to the commit processing requested by the above, the transaction management device requested by the commit response step that responds with a successful commit to the application when any of the processing device power responses is received, and the commit request step.
  • a failure processing device which is a powerful processing device that cannot respond to a commit process due to a failure, also recovers its failure power, the transaction management device performs a powerful transaction without the response.
  • the transaction management device requests commit processing from a plurality of processing devices in response to a commit request from the application, and the processing device has the capability of transaction management device power except for the failure of the device itself. Commit processing is always performed in response to a commit processing request and responded to the transaction management device. If there is a response from the transaction management device power V or any other processing device power to the requested commit processing, the application is responded.
  • the failure processing device which is a powerful processing device that cannot respond to the requested commit processing due to a failure, recovers the failure power
  • the transaction management device Processing other outstanding transactions by processing unresolved transactions, which are powerful transactions that have not been answered. Based on the processing result of the device! /,
  • the failure processing device processes the unresolved transaction based on the instruction of the transaction management device power As a result, consistency between databases can be maintained by one-phase commit.
  • FIG. 1 is a functional block diagram showing a system configuration of a distributed transaction processing system according to the present embodiment.
  • FIG. 2 is a diagram showing an example of a data structure of an entry created in the RowID file corresponding to each record.
  • FIG. 3 is a diagram showing an example of a data structure of an unresolved transaction list included in a log file.
  • FIG. 4 is a flowchart showing a processing procedure of a commit process by a conductor.
  • FIG. 5 is a flowchart showing a processing procedure of director recovery processing by the director recovery processing unit shown in FIG.
  • FIG. 6 is a flowchart showing a processing procedure of commit recovery processing by the conductor recovery processing unit shown in FIG.
  • FIG. 7 is a flowchart of a transaction result determination process performed by the transaction result determination unit shown in FIG.
  • FIG. 8 is a diagram showing a database consistency maintaining operation corresponding to each timing when the director goes down when two directors process a distributed transaction.
  • FIG. 9 is a diagram illustrating a computer that executes a conductor program and a director program according to the present embodiment.
  • FIG. 1 shows a system configuration of the distributed transaction processing system according to the present embodiment.
  • this distributed transaction processing system includes a conductor 100 that receives a transaction from an application, and n directors 200-200 that perform distributed processing of the transaction received by the conductor 100 via a network 40.
  • the conductor 100 instructs the directors involved in the distributed processing of transactions that have received application power via the network 40, and responds to the application with the transaction processing results based on the processing results of each director! Device.
  • the conductor 100 performs commit processing by one-phase commit.
  • Director 200-200 also commits due to failure
  • the conductor 100 includes a request processing unit 110, a response processing unit 120, a director recovery processing unit 130, a conductor recovery processing unit 140, a transaction result determination unit 150, and a communication unit 160.
  • the request processing unit 110 is a processing unit that receives a transaction from an application and instructs a related director to distribute the received transaction.
  • the request processing unit 110 requests the relevant director to perform a commit process when the application capability also receives a commit request.
  • the request processing unit 110 notifies the application of the commit failure. To do.
  • the response processing unit 120 receives the director power distributed transaction processing result instructed by the request processing unit 110 to perform transaction distributed processing, and notifies the application of the transaction processing result based on the distributed transaction processing result of each director. It is a processing part.
  • the response processing unit 120 When the response processing unit 120 receives a response from one of the directors instructed to commit by the request processing unit 110, the response processing unit 120 indicates that the commit has been successful. -Notify Chillon.
  • the response processing unit 120 does not respond within a predetermined time from any of the directors to which the request processing unit 110 is instructed to perform commit processing, that is, all the directors instructed to perform commit processing. If it goes down after receiving the commit processing instruction, it notifies the application that the result of the commit processing is unknown.
  • the director recovery processing unit 130 has a director who is down in the directors 200-200.
  • it is a processing unit that monitors whether the failed director has recovered, and performs recovery processing when the director recovers.
  • the director recovery processing unit 130 performs a commit process on the recovered director, queries an unresolved transaction, and if there is an unresolved transaction, The transaction result determination unit 150 is used to determine processing to be performed for the unresolved transaction, and the determined processing is instructed to the restored director.
  • This director recovery processing unit 130 performs commit processing on the recovered director, queries unresolved transactions, and if there are unresolved transactions, uses transaction result determination unit 150. By determining the processing to be performed on the unresolved transaction and instructing the restored director to the recovered director, the consistency between databases can be ensured even if there is a director down during commit processing. Can do.
  • the response processing unit 120 when the response processing unit 120 receives any director power response, it immediately notifies the application of the success of the commit, and after the commit processing request is received to the remaining director, it is down before the response to the conductor 100. Even if there is a director, the director can perform commit processing after recovery, and guarantee consistency between databases.
  • the conductor recovery processing unit 140 is a processing unit that performs recovery processing when the conductor 100 goes down and recovers.
  • the conductor recovery processing unit 140 processes unresolved transactions as part of the recovery processing.
  • the conductor restoration processing unit 140 is provided for all directors 200-200.
  • the transaction result determination unit 150 is used to determine the processing to be performed on the unresolved transaction, and the determined processing is instructed to the director who has responded to the unresolved transaction.
  • the transaction result determination unit 150 is used to perform processing to be performed on the unresolved transaction.
  • Director 200-200 by determining and directing the determined processing to the director who responded the outstanding transaction.
  • the transaction result determination unit 150 is a processing unit that determines a process to be performed on an unresolved transaction in accordance with instructions from the director recovery processing unit 130 and the conductor recovery processing unit 140.
  • the transaction result determination unit 150 inquires the other director about the commit result for the unresolved transaction, and performs the process to be performed for the unresolved transaction based on the commit result of the other director. To decide.
  • the transaction result determination unit 150 determines the processing to be performed on the unresolved transaction as commit processing.
  • the transaction result determination unit 150 determines the processing to be performed on the unresolved transaction as commit processing.
  • another director performs a callback for a transaction, it decides to roll back the processing to be performed for the outstanding transaction.
  • the communication unit 160 is a computer or director 200-200 that executes an application.
  • 1 n is a processing unit that communicates with each other via the network 40, and receives commit requests from the application and responses of 200-200 directors.
  • Director 200 200 needs access to handle distributed transactions
  • the director 200 includes a transaction processing unit 210 and an unresolved transaction response unit 22.
  • the transaction processing unit 210 is a processing unit that receives a transaction processing request from the conductor 100, performs distributed processing of transactions, and updates the data file 10 that stores data in a record format.
  • the transaction processing unit 210 updates the RowID file 20 that stores the storage position of the record in the data file 10 and the log file 30 that stores the transaction log.
  • FIG. 2 is a diagram showing an example of a data structure of an entry created in the RowID file 20 corresponding to each record. As shown in the figure, this entry includes a record storage location and a transaction ID.
  • the record storage position indicates the storage position of the record in the data file 10.
  • the transaction ID is an identifier for identifying the transaction that lastly performed the addition “deletion” update of the record corresponding to this entry, and is updated by the transaction processing unit 210 when the transaction processing is completed.
  • FIG. 3 is a diagram illustrating an example of a data structure of an unresolved transaction list included in the log file 30. As shown in the figure, this unresolved transaction list contains the transaction IDs that are the identifiers of the m transactions that have been committed.
  • the unresolved transaction response unit 220 is a processing unit that responds to the conductor 100 with the transaction ID stored in the unresolved transaction list of the log file 30 in response to the unresolved transaction inquiry from the conductor 100.
  • the unresolved transaction response unit 220 responds to the inquiry from the conductor 100 with an unresolved transaction, so that the conductor 100 is in contact with the director 200.
  • unresolved transaction response unit 220 uses the unresolved transaction list in the log file 30 and the RowID file 20 in response to a query of commit results regarding unresolved transactions of other directors from the conductor 100. Responds to conductor 100.
  • the unresolved transaction response unit 220 receives the transaction ID of the unresolved transaction from the conductor 100 and responds that the commit has not been completed if the transaction ID is in the unresolved transaction list. If it is not in the list of unresolved transactions, it is checked whether it is in the RowID file 20. If it is in the RowID file 20, the transaction has been committed, so the commit completion response is returned, and it is not in the RowID file 20. Responds with incomplete commit since the transaction has not been committed.
  • This unresolved transaction response unit 220 forces the completion of commit using the unresolved transaction list in the log file 30 and the RowID file 20 in response to the inquiry of commit results regarding unresolved transactions of other directors from the conductor 100. By responding to the conductor 100, the conductor 100 can decide what to do with the outstanding transactions of other directors.
  • the communication unit 230 is a processing unit that communicates with the conductor 100 or the like via the network 40. For example, the communication unit 230 receives a commit processing request or an unresolved transaction query from the conductor 100, and the conductor 100 receives a commit result or an unresolved result. Send the transaction ID of the resolution transaction.
  • FIG. 4 is a flowchart showing a processing procedure of commit processing by the conductor 100.
  • the request processing unit 110 receives a commit request from the application (step S101), and transmits a commit processing request to the related director group (step S102).
  • Step SI 08 it is determined whether or not it is possible to send a commit processing request to one of the directors. If no commit processing request can be sent to any director, Because the director is down, the commit failure is passed to the application. (Step SI 08)
  • Step S104 If any director force responds (step S104, affirmative), the application successfully commits. (Step S 105), and if there is no response from the director of V or deviation, it is determined whether or not the force is a timeout (Step S 106).
  • the conductor 100 sends a commit processing request to the director and immediately notifies the application of the commit success when any director response is received, so the commit request from the application is processed at high speed. can do.
  • FIG. 5 is a flowchart showing a processing procedure of director recovery processing by the director recovery processing unit 130 shown in FIG.
  • the director recovery processing unit 130 periodically tries to connect to the down director (step S201). (Step S202).
  • step S203 it is determined whether or not there is an unresolved transaction. If there is an unresolved transaction, one unresolved transaction is selected (step S204), and the selected unresolved transaction is selected. Transaction result determination processing for determining processing to be performed is performed (step S205).
  • step S206 it is determined whether or not the processing to be performed on the unresolved transaction is determined, that is, whether or not commit or rollback is determined (step S206), and when the commit power rollback is determined. Instructs the recovered director to process the unresolved transaction based on the determination result (step S207), and returns to step S203 to proceed to the next unresolved transaction.
  • the director recovery processing unit 130 determines the unresolved transaction processing of the recovered director by the transaction result determination processing, and instructs the recovered director to execute the determined processing before the commit processing. Commit processing of a director that has been downed can be performed correctly after recovery.
  • FIG. 6 is a flowchart showing a processing procedure of commit recovery processing by the conductor recovery processing unit 140 shown in FIG.
  • this conductor restoration processing unit 140 selects one director after restoring the down force (step S301), and inquires about an unresolved transaction (step S302).
  • step S303 it is determined whether or not there is an unresolved transaction. If there is no unresolved transaction, it is determined whether or not all directors have been processed (step S304). If not, the process returns to step S301 to move to the next director, and if all directors have been processed, the process ends.
  • Step S305 transaction result determination processing for determining processing to be performed on the selected unresolved transaction is performed (Step S306).
  • step S307 it is determined whether or not the processing to be performed on the unresolved transaction is determined, that is, whether or not commit or rollback is determined (step S307), and when the commit power rollback is determined. Selects and directs the director to process an unresolved transaction based on the decision result (step S308), and returns to step S303 to process the next unresolved transaction. Move.
  • the conductor recovery processing unit 140 sends an unresolved transaction to the director.
  • Conducts a query determines the processing to be performed for unresolved transactions by the transaction result determination processing, and instructs the director to determine the processing, so that the conductor 100 transmits the commit request to some directors. Even if it goes down, the remaining directors can commit correctly after recovery.
  • FIG. 7 is a flowchart showing a processing procedure of transaction result determination processing by the transaction result determination unit 150 shown in FIG.
  • the transaction result determination process corresponds to the process in step S205 in FIG. 5 and the process in step S306 in FIG.
  • the transaction result determination unit 150 determines whether or not the state of the unresolved transaction is incomplete (step S401), and the state of the unresolved transaction is incomplete. In such a case, the process is terminated with the result as uncertain (step S412).
  • step S403 the number of down directors is initialized to "0" as a variable for counting the number of down directors.
  • the selected director is inquired about the processing result of the unresolved transaction (step S404), and it is determined whether or not the director is down! / (Step S405).
  • step S406 it is determined whether the response to the query of the outstanding transaction processing result is a commit. Ends the processing with the result as a commit (step S407).
  • step S409 To determine whether all directors have been inquired.
  • step S408 the number of down directors is set to “1” (step S408), and it is determined whether or not all directors have been inquired (step S409).
  • step S410 it is determined whether or not the number of down directors is “0” (step S410).
  • step S411 If the number of down directors is "0", all directors have not committed, so the result is rolled back (step S411), and the number of down directors is "0". If not, since the processing result of the unresolved transaction by the director is unknown, the processing is terminated with the result as unconfirmed (step S412).
  • the transaction result determination unit 150 sequentially inquires the director about the commit results of the unresolved transactions. If there is a director that has committed, the transaction result determination unit 150 determines that the result of the unresolved transaction is commit, and all directors In the event that is uncommitted, it is possible to eliminate logging of transaction processing results by conductor 100 by determining the outcome of outstanding transactions as rollback.
  • FIG. 8 is a diagram showing a database consistency maintaining operation corresponding to each timing when the director goes down when two directors process a distributed transaction.
  • the response to the application in response to the commit request is a commit success, and the transaction result is a commit.
  • no action is required to maintain consistency between databases.
  • the response to the application in response to a commit request related to the down timing is a commit success, and the transaction result is a commit.
  • D After restarting, D knows that D is committed through conductor 100 and commits. Also
  • Director D goes down before accepting the commit instruction, and Director D also commits If it goes down before accepting an indication, the response to the application for the commit request will be a commit failure, the transaction result will be rolled back, and D and D will be
  • Director D goes down before accepting the commit instruction, and Director D force commits.
  • Director D goes down during commit processing, and Director D downloads before commit response.
  • Director D goes down before commit response, and Director D also down before commit response.
  • the request processing unit 110 transmits a commit processing request to a director related to a commit request having an application capability, and the response processing unit 120 responds to any director force response. Commit to application successfully if received If the director goes down and there are unresolved transactions, when the director recovers, the director recovery processing unit 130 processes unresolved transactions based on the results of unresolved transaction processing by other directors. Therefore, the consistency between databases can be maintained by one-phase commit, and the commit process can be speeded up.
  • the conductor recovery processing unit 140 sends each director after recovery.
  • the director responds to the unresolved transaction based on the processing result of the other director for the unresolved transaction to which the director responded. Therefore, it is possible to maintain the consistency between the databases and to speed up the commit process.
  • a conductor program and a director program having similar functions can be obtained by realizing the configuration of the force conductor and the director described for the conductor and the director by software.
  • a computer that executes these conductor programs and director programs will be described.
  • FIG. 9 is a diagram illustrating a computer that executes the conductor program and the director program according to the present embodiment. It should be noted that here, the force conductor program and the director program, which explain the case where the conductor program and the director program are executed on one computer, can be executed on another computer. It is also possible to execute the application and conductor program on a single computer.
  • the computer 300 includes an HDD 310, a RAM 320, a ROM 330, a CPU 340, a LAN interface 350, and an I / O interface 360.
  • the HDD 310 stores a conductor program 311 and a director program 312. It is a storage device and also stores a data file 10, a RowID file 20 and a log file 30 used by the director program 312.
  • the RAM 320 is a memory that stores the conductor program 311 and the director program 312 read from the HDD 310, the execution result of the program, and the like.
  • 0 is a read-only memory that stores constants and the like.
  • the CPU 340 reads the conductor program 311 and the director program 3 from the RAM 320.
  • 12 is a processing device that reads 12 and executes them as a conductor process 341 and a director process 342.
  • the LAN interface 350 is an interface for connecting to a LAN (network)
  • the IZO interface 360 is an interface for connecting an input device such as a keyboard and a mouse and a display device.
  • the conductor program 311 and the director program 312 executed in the computer 300 are stored in a portable storage medium such as a floppy disk (FD), a CD-ROM, a DVD disk, a magneto-optical disk, and an IC card. These storage media powers are read and installed in the computer 300.
  • a portable storage medium such as a floppy disk (FD), a CD-ROM, a DVD disk, a magneto-optical disk, and an IC card.
  • the conductor program 311 and the director program 312 are stored in a database or the like of another computer connected via the LAN interface 350, read from the database or the like, and installed in the computer 300.
  • the installed conductor program 311 and director program 312 are stored in the HDD 310.
  • the distributed transaction processing program, the distributed transaction processing method, and the distributed transaction processing device according to the present invention are useful for a distributed transaction system, and are particularly suitable for a case where high speed commit processing is desired. Yes.

Landscapes

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

Abstract

 アプリケーションからのコミット要求に対して関連するディレクタに要求処理部がコミット処理要求を送信し、応答処理部がいずれかのディレクタから応答を受け取った場合にアプリケーションにコミットの成功を通知し、ディレクタがダウンして未解決トランザクションがある場合には、ディレクタが復旧した際に、ディレクタ復旧処理部が他のディレクタによる未解決トランザクションの処理結果に基づいて未解決トランザクションの処理を復旧したディレクタに指示する。また、ディレクタにコミット処理要求を送信中にコンダクタがダウンして一部のディレクタにコミット処理要求が送信できなかった場合には、コンダクタ復旧処理部が復旧後に各ディレクタに対して未解決トランザクションの問合せを行い、ディレクタが応答した未解決トランザクションに対する他のディレクタの処理結果に基づいて未解決トランザクションの処理を、応答したディレクタに指示する。

Description

明 細 書
分散トランザクション処理プログラム、分散トランザクション処理方法および 分散トランザクション処理装置
技術分野
[0001] 本発明は、装置自身の故障以外ではコミット処理要求に対して必ずコミット処理を 行って応答する複数の処理装置にアプリケーション力 受け付けたトランザクションの 分散処理を指示する分散トランザクション処理プログラム、分散トランザクション処理 方法および分散トランザクション処理装置に関し、特に、コミット処理を高速に行うとと もに、導入'運用の負担を軽減することができる分散トランザクション処理プログラム、 分散トランザクション処理方法および分散トランザクション処理装置に関するものであ る。
背景技術
[0002] 従来、一つのトランザクションを処理する場合に複数のデータベースに対してァクセ スする必要がある分散トランザクション処理では、複数のデータベース間の整合性を 保証するために、 2フェーズコミットが用いられてきた。
[0003] 2フェーズコミットでは、コミット処理を 2段階のフェーズにわけ、第 1段階でデータべ ースに対してコミットの準備ができているか否かを確認し (プリペア)、全てのデータべ ース力 コミットの準備ができたことが確認できた場合にのみ第 2段階でコミットを実行 し、それ以外の場合には第 2段階でロールバックを行うことによってデータベース間 の整合性を保証している (例えば、非特許文献 1参照。 ) o
[0004] 非特許文献 1 :「分散トランザクションに挑戦しょう!」、 [平成 16年 10月 12日検索]、 インターネットく URL: HYPERLINK
http://www.microsoft.eom/japan/enabie/training/kblight/t004/7/0l.htm http://www.ogis-n.co.jp/otc/hiroba/technical/DTP/step2 >
発明の開示
発明が解決しょうとする課題
[0005] しかしながら、 2フェーズコミットでは、コミット処理を 2段階のフェーズにわけて行うた めに、処理効率が悪いという問題がある。また、分散トランザクション処理を管理するト ランザクシヨンマネージャを実行するコンピュータに障害が発生した場合にトランザク シヨンマネージャが復旧処理で使用するトランザクションログが必要であり、トランザク シヨンログのための導入 '運用の負担が大きいという問題もある。
[0006] 本発明は、上記に鑑みてなされたものであって、コミット処理を高速に行うとともに、 導入 '運用の負担を軽減することができる分散トランザクション処理プログラム、分散ト ランザクシヨン処理方法および分散トランザクション処理装置を提供することを目的と する。
課題を解決するための手段
[0007] 上述した課題を解決し、 目的を達成するため、請求項 1の発明に係る分散トランザ クシヨン処理プログラムは、装置自身の故障以外ではコミット処理要求に対して必ず コミット処理を行って応答する複数の処理装置にアプリケーション力 受け付けたトラ ンザクシヨンの分散処理を指示する分散トランザクション処理プログラムであって、前 記アプリケーションからのコミット要求に対して複数の処理装置にコミット処理を要求 するコミット要求手順と、前記コミット要求手順により要求したコミット処理に対してい ずれかの処理装置力 応答があった場合に前記アプリケーションに対してコミットの 成功を応答するコミット応答手順と、前記コミット要求手順により要求したコミット処理 に対して故障に起因して応答を行うことができな力つた処理装置である故障処理装 置が故障力も復旧した際に、該応答が行われな力つたトランザクションである未解決ト ランザクシヨンの処理にっ 、て他の処理装置の処理結果に基づ!/、て該故障処理装 置に対して指示する復旧指示手順と、をコンピュータに実行させることを特徴とする。
[0008] この請求項 1の発明によれば、アプリケーションからのコミット要求に対して複数の 処理装置にコミット処理を要求し、要求したコミット処理に対して 、ずれかの処理装置 力も応答があった場合にアプリケーションに対してコミットの成功を応答し、要求した コミット処理に対して故障に起因して応答を行うことができな力つた処理装置である故 障処理装置が故障力も復旧した際に、応答が行われな力つたトランザクションである 未解決トランザクションの処理にっ 、て他の処理装置の処理結果に基づ 、て故障処 理装置に対して指示するよう構成したので、 1フェーズコミットによってデータベース 間の整合性を維持することができる。
[0009] また、請求項 2の発明に係る分散トランザクション処理プログラムは、請求項 1の発 明において、前記復旧指示手順は、前記故障処理装置が復旧した力否かを判定す る復旧判定手順と、前記復旧判定手順により故障処理装置が復旧したと判定された 場合に、故障処理装置の未解決トランザクションの処理結果につ 、て他の処理装置 に問合せを行 、、問合せ結果に基づ 、て未解決トランザクションに対する処理を故 障処理装置に要求する処理装置復旧処理手順とを、コンピュータに実行させることを 特徴とする。
[0010] この請求項 2の発明によれば、故障処理装置が復旧した力否かを判定し、故障処 理装置が復旧したと判定した場合に、故障処理装置の未解決トランザクションの処理 結果につ 1ヽて他の処理装置に問合せを行 ヽ、問合せ結果に基づ!ヽて未解決トラン ザクシヨンに対する処理を故障処理装置に要求するよう構成したので、処理装置によ るトランザクションログの管理だけが必要であり、当該分散トランザクション処理プログ ラムによるトランザクションログの管理を不要とすることができる。
[0011] また、請求項 3の発明に係る分散トランザクション処理プログラムは、請求項 2の発 明において、前記復旧判定手順は、前記故障処理装置に対して定期的に接続を確 認することによって該故障処理装置が復旧したか否かを判定することを特徴とする。
[0012] この請求項 3の発明によれば、故障処理装置に対して定期的に接続を確認するこ とによって故障処理装置が復旧した力否かを判定するよう構成したので、確実に故障 処理装置の復旧を検知することができる。
[0013] また、請求項 4の発明に係る分散トランザクション処理プログラムは、請求項 1、 2ま たは 3の発明にお 、て、自装置の故障からの復旧時に処理装置に対して未解決トラ ンザクシヨンを問 1ヽ合わせる未解決問合せを行!ヽ、該未解決問合せに対して処理装 置力 応答された未解決トランザクションの処理結果について他の処理装置に問い 合わせる処理結果問合せを行う未解決トランザクション処理結果問合せ手順と、前記 未解決トランザクション処理結果問合せ手順による処理結果問合せに対する応答結 果に基づいて該未解決トランザクションに対する処理を未解決問合せに対して未解 決トランザクションを応答した処理装置に要求する自装置復旧処理手順とを、さらに コンピュータに実行させることを特徴とする。
[0014] この請求項 4の発明によれば、自装置の故障力 の復旧時に処理装置に対して未 解決トランザクションを問 ヽ合わせる未解決問合せを行 ヽ、未解決問合せに対して処 理装置力 応答された未解決トランザクションの処理結果について他の処理装置に 問!、合わせる処理結果問合せを行!、、処理結果問合せに対する応答結果に基づ 、 て未解決トランザクションに対する処理を未解決問合せに対して未解決トランザクショ ンを応答した処理装置に要求するよう構成したので、当該分散トランザクション処理 プログラムを実行するコンピュータが一部の処理装置に対してコミット処理を要求した 後に故障した場合にも、復旧後に残りの処理装置のコミット処理を正しく行うことがで きる。
[0015] また、請求項 5の発明に係る分散トランザクション処理プログラムは、請求項 1の発 明において、前記コミット要求手順は、コミット処理の要求がいずれの処理装置にも 受け付けられなかった場合に、前記アプリケーションに対してコミットの失敗を応答す ることを特徴とする。
[0016] この請求項 5の発明によれば、コミット処理の要求がいずれの処理装置にも受け付 けられな力つた場合に、アプリケーションに対してコミットの失敗を応答するよう構成し たので、コミット処理を要求した全ての処理装置が故障して!/、る場合にもアプリケーシ ヨンに迅速に応答することができる。
[0017] また、請求項 6の発明に係る分散トランザクション処理プログラムは、請求項 1の発 明において、前記コミット応答手順は、前記コミット要求手順により要求したコミット処 理に対して 、ずれの処理装置力もも応答がな力つた場合には、前記アプリケーション にコミット結果を不明と応答することを特徴とする。
[0018] この請求項 6の発明によれば、要求したコミット処理に対していずれの処理装置から も応答がな力つた場合には、アプリケーションにコミット結果を不明と応答するよう構 成したので、コミット処理を要求した全ての処理装置が要求受付後に故障した場合に もアプリケーションに確実に応答することができる。
[0019] また、請求項 7の発明に係る分散トランザクション処理方法は、装置自身の故障以 外ではコミット処理要求に対して必ずコミット処理を行って応答する複数の処理装置 にアプリケーション力 受け付けたトランザクションの分散処理を指示する分散トラン ザクシヨン処理方法であって、前記アプリケーション力 のコミット要求に対して複数の 処理装置にコミット処理を要求するコミット要求工程と、前記コミット要求工程により要 求したコミット処理に対していずれかの処理装置力 応答があった場合に前記アプリ ケーシヨンに対してコミットの成功を応答するコミット応答工程と、前記コミット要求ェ 程により要求したコミット処理に対して故障に起因して応答を行うことができな力つた 処理装置である故障処理装置が故障力も復旧した際に、該応答が行われな力つたト ランザクシヨンである未解決トランザクションの処理について他の処理装置の処理結 果に基づいて該故障処理装置に対して指示する復旧指示工程と、を含んだことを特 徴とする。
[0020] この請求項 7の発明によれば、アプリケーションからのコミット要求に対して複数の 処理装置にコミット処理を要求し、要求したコミット処理に対して 、ずれかの処理装置 力も応答があった場合にアプリケーションに対してコミットの成功を応答し、要求した コミット処理に対して故障に起因して応答を行うことができな力つた処理装置である故 障処理装置が故障力も復旧した際に、応答が行われな力つたトランザクションである 未解決トランザクションの処理にっ 、て他の処理装置の処理結果に基づ 、て故障処 理装置に対して指示するよう構成したので、 1フェーズコミットによってデータベース 間の整合性を維持することができる。
[0021] また、請求項 8の発明に係る分散トランザクション処理装置は、装置自身の故障以 外ではコミット処理要求に対して必ずコミット処理を行って応答する複数の処理装置 にアプリケーション力 受け付けたトランザクションの分散処理を指示する分散トラン ザクシヨン処理装置であって、前記アプリケーション力 のコミット要求に対して複数の 処理装置にコミット処理を要求するコミット要求手段と、前記コミット要求手段により要 求したコミット処理に対していずれかの処理装置力 応答があった場合に前記アプリ ケーシヨンに対してコミットの成功を応答するコミット応答手段と、前記コミット要求手 段により要求したコミット処理に対して故障に起因して応答を行うことができな力つた 処理装置である故障処理装置が故障力も復旧した際に、該応答が行われな力つたト ランザクシヨンである未解決トランザクションの処理について他の処理装置の処理結 果に基づいて該故障処理装置に対して指示する復旧指示手段と、を備えたことを特 徴とする。
[0022] この請求項 8の発明によれば、アプリケーションからのコミット要求に対して複数の 処理装置にコミット処理を要求し、要求したコミット処理に対して 、ずれかの処理装置 力も応答があった場合にアプリケーションに対してコミットの成功を応答し、要求した コミット処理に対して故障に起因して応答を行うことができな力つた処理装置である故 障処理装置が故障力も復旧した際に、応答が行われな力つたトランザクションである 未解決トランザクションの処理にっ 、て他の処理装置の処理結果に基づ 、て故障処 理装置に対して指示するよう構成したので、 1フェーズコミットによってデータベース 間の整合性を維持することができる。
[0023] また、請求項 9の発明に係る分散トランザクション処理装置は、一つのトランザクショ ンを分散処理する複数の処理装置と、アプリケーションからトランザクション処理要求 を受け付けて該複数の処理装置に分散処理を要求するトランザクション管理装置と 力も構成される分散トランザクション処理装置であって、前記トランザクション管理装 置は、前記アプリケーション力 のコミット要求に対して複数の処理装置にコミット処理 を要求するコミット要求手段と、前記コミット要求手段により要求したコミット処理に対 していずれかの処理装置力 応答があった場合に前記アプリケーションに対してコミ ットの成功を応答するコミット応答手段と、前記コミット要求手段により要求したコミット 処理に対して故障に起因して応答を行うことができな力つた処理装置である故障処 理装置が故障力も復旧した際に、該応答が行われな力つたトランザクションである未 解決トランザクションの処理にっ 、て他の処理装置の処理結果に基づ 、て該故障処 理装置に対して指示する復旧指示手段と、を備え、前記処理装置は、装置自身の故 障以外では前記トランザクション管理装置からのコミット処理要求に対して必ずコミット 処理を行って該トランザクション管理装置に応答することができるコミット処理手段と、 故障力も復旧した際に、前記トランザクション管理装置からの指示に基づいて前記未 解決トランザクションの処理を行う復旧処理手段と、を備えたことを特徴とする。
[0024] この請求項 9の発明によれば、トランザクション管理装置は、アプリケーションからの コミット要求に対して複数の処理装置にコミット処理を要求し、要求したコミット処理に 対していずれかの処理装置力 応答があった場合にアプリケーションに対してコミット の成功を応答し、要求したコミット処理に対して故障に起因して応答を行うことができ な力つた処理装置である故障処理装置が故障力も復旧した際に、応答が行われなか つたトランザクションである未解決トランザクションの処理について他の処理装置の処 理結果に基づいて故障処理装置に対して指示し、処理装置は、装置自身の故障以 外ではトランザクション管理装置からのコミット処理要求に対して必ずコミット処理を行 つてトランザクション管理装置に応答することができ、故障力も復旧した際に、トランザ クシヨン管理装置力 の指示に基づいて未解決トランザクションの処理を行うよう構成 したので、 1フェーズコミットによってデータベース間の整合性を維持することができる また、請求項 10の発明に係る分散トランザクション処理方法は、一つのトランザクシ ヨンを分散処理する複数の処理装置と、アプリケーションからトランザクション処理要 求を受け付けて該複数の処理装置に分散処理を要求するトランザクション管理装置 とから構成される分散トランザクション処理装置のコミット処理方法であって、前記トラ ンザクシヨン管理装置が前記アプリケーションからのコミット要求に対して複数の処理 装置にコミット処理を要求するコミット要求工程と、前記処理装置が装置自身の故障 以外では前記トランザクション管理装置からのコミット処理要求に対して必ずコミット処 理を行って該トランザクション管理装置に応答するコミット処理工程と、前記コミット要 求工程により要求したコミット処理に対して、前記トランザクション管理装置が、いずれ かの処理装置力 応答があった場合に前記アプリケーションに対してコミットの成功 を応答するコミット応答工程と、前記コミット要求工程により要求したコミット処理に対 して故障に起因して応答を行うことができな力つた処理装置である故障処理装置が 故障力も復旧した際に、前記トランザクション管理装置が、該応答が行われな力つた トランザクションである未解決トランザクションの処理について他の処理装置の処理結 果に基づいて該故障処理装置に対して指示する復旧指示工程と、故障から復旧し た際に、前記故障処理装置が、前記トランザクション管理装置からの指示に基づいて 前記未解決トランザクションの処理を行う復旧処理工程と、を含んだことを特徴とする [0026] この請求項 10の発明によれば、トランザクション管理装置がアプリケーションからの コミット要求に対して複数の処理装置にコミット処理を要求し、処理装置が装置自身 の故障以外ではトランザクション管理装置力 のコミット処理要求に対して必ずコミット 処理を行ってトランザクション管理装置に応答し、要求したコミット処理に対して、トラ ンザクシヨン管理装置力 V、ずれかの処理装置力 応答があった場合にアプリケーシ ヨンに対してコミットの成功を応答し、要求したコミット処理に対して故障に起因して応 答を行うことができな力つた処理装置である故障処理装置が故障力も復旧した際に、 トランザクション管理装置が、応答が行われな力つたトランザクションである未解決トラ ンザクシヨンの処理にっ 、て他の処理装置の処理結果に基づ!/、て故障処理装置に 対して指示し、故障力も復旧した際に、故障処理装置が、トランザクション管理装置 力 の指示に基づいて未解決トランザクションの処理を行うよう構成したので、 1フエ ーズコミットによってデータベース間の整合性を維持することができる。 発明の効果
[0027] 請求項 1、 7、 8、 9および 10の発明によれば、 1フェーズコミットによってデータべ一 ス間の整合性を維持することができるので、コミット処理を高速に行うことができるとい う効果を奏する。
[0028] また、請求項 2の発明によれば、処理装置によるトランザクションログの管理だけが 必要であり、当該分散トランザクション処理プログラムによるトランザクションログの管 理を不要とするので、導入'運用の負担を軽減することができるという効果を奏する。
[0029] また、請求項 3の発明によれば、確実に故障処理装置の復旧を検知するので、デ ータベース間の整合性を確実に維持することができるという効果を奏する。
[0030] また、請求項 4の発明によれば、当該分散トランザクション処理プログラムを実行す るコンピュータが一部の処理装置に対してコミット処理を要求した後に故障した場合 にも、復旧後に残りの処理装置のコミット処理を正しく行うことができるので、 1フエ一 ズコミットによってデータベース間の整合性を維持することができるという効果を奏す る。
[0031] また、請求項 5の発明によれば、コミット処理を要求した全ての処理装置が故障して V、る場合にアプリケーションに迅速に応答するので、コミット処理を高速に行うことが できるという効果を奏する。
[0032] また、請求項 6の発明によれば、コミット処理を要求した全ての処理装置が要求受 付後に故障した場合にもアプリケーションに確実に応答することができるので、アプリ ケーシヨンは適切な復旧動作行うことができるという効果を奏する。
図面の簡単な説明
[0033] [図 1]図 1は、本実施例に係る分散トランザクション処理システムのシステム構成を示 す機能ブロック図である。
[図 2]図 2は、各レコードに対応して RowIDファイルに作成されるエントリのデータ構 造の一例を示す図である。
[図 3]図 3は、ログファイルに含まれる未解決トランザクション一覧のデータ構造の一例 を示す図である。
[図 4]図 4は、コンダクタによるコミット処理の処理手順を示すフローチャートである。
[図 5]図 5は、図 1に示したディレクタ復旧処理部によるディレクタ復旧処理の処理手 順を示すフローチャートである。
[図 6]図 6は、図 1に示したコンダクタ復旧処理部によるコミット復旧処理の処理手順を 示すフローチャートである。
[図 7]図 7は、図 1に示したトランザクション結果決定部によるトランザクション結果決定 処理の処理手順を示すフローチャートである。
[図 8]図 8は、 2台のディレクタが分散トランザクションを処理する場合に、ディレクタが ダウンする各タイミングに対応するデータベース整合性維持動作を示す図である。
[図 9]図 9は、本実施例に係るコンダクタプログラムおよびディレクタプログラムを実行 するコンピュータを示す図である。
符号の説明
[0034] 10 データファイル
20 RowIDファイル
30 ログファイル
40 ネットワーク
100 コンダクタ 110 要求処理部
120 応答処理部
130 ディレクタ復旧処理部
140 コンダクタ復旧処理部
150 トランザクション結果決定部
160 通信部
200 - "200 ディレクタ
1 n
210 トランザクション処理部
220 未解決トランザクション応答部
230 通信部
300 コンピュータ
310 HDD
311 コンダクタプログラム
312 ディレクタプログラム
320 RAM
330 ROM
340 CPU
341 コンダクタプロセス
342 ディレクタプロセス
350 LANインタフェース
360 I/Oインタフェース
発明を実施するための最良の形態
[0035] 以下に、本発明に係る分散トランザクション処理プログラム、分散トランザクション処 理方法および分散トランザクション処理装置の実施例を図面に基づいて詳細に説明 する。なお、この実施例によりこの発明が限定されるものではない。
実施例
[0036] まず、本実施例に係る分散トランザクション処理システムの構成について説明する。
図 1は、本実施例に係る分散トランザクション処理システムのシステム構成を示す機 能ブロック図である。
[0037] 同図に示すように、この分散トランザクション処理システムは、アプリケーションからト ランザクシヨンを受け付けるコンダクタ 100と、コンダクタ 100によって受け付けられた トランザクションを分散処理する n台のディレクタ 200— 200がネットワーク 40を介し
1 n
て接続されて構成される。
[0038] コンダクタ 100は、ネットワーク 40を介してアプリケーション力も受け付けたトランザク シヨンの分散処理を関係するディレクタに指示し、各ディレクタの処理結果に基づ!/ヽ てトランザクションの処理結果をアプリケーションに応答する装置である。
[0039] なお、この分散トランザクション処理システムでは、コンダクタ 100は、 1フェーズコミ ットによってコミット処理を行う。また、ディレクタ 200— 200は、故障によってコミット
1 n
処理を行えな 、場合以外は、コミット処理要求を受け付けると必ずコミット処理を行う ことがでさるちのとする。
[0040] コンダクタ 100は、要求処理部 110と、応答処理部 120と、ディレクタ復旧処理部 1 30と、コンダクタ復旧処理部 140と、トランザクション結果決定部 150と、通信部 160 とを有する。
[0041] 要求処理部 110は、アプリケーションからトランザクションを受け付け、受け付けたト ランザクシヨンの分散処理を関係するディレクタに指示する処理部である。この要求 処理部 110は、アプリケーション力もコミット要求を受け付けた場合には、関係するデ ィレクタにコミット処理を要求する。
[0042] ここで、関係する全てのディレクタがダウンして 、て、 、ずれのディレクタにもコミット 処理を依頼することができない場合には、この要求処理部 110は、アプリケーション にコミットの失敗を通知する。
[0043] 応答処理部 120は、要求処理部 110によりトランザクションの分散処理を指示され たディレクタ力 分散トランザクション処理結果を受け取り、各ディレクタの分散トラン ザクシヨン処理結果に基づいてアプリケーションにトランザクション処理結果を通知す る処理部である。
[0044] この応答処理部 120は、要求処理部 110によりコミット処理を指示されたディレクタ のぅちの 、ずれかのディレクタ力 応答を受け取ると、コミットが成功したことをアプリケ ーシヨンに通知する。
[0045] また、この応答処理部 120は、要求処理部 110によりコミット処理を指示されたいず れのディレクタからも所定の時間内に応答がない場合、すなわち、コミット処理を指示 された全てのディレクタがコミット処理の指示を受信後にダウンした場合には、アプリ ケーシヨンにコミット処理の結果が不明であることを通知する。
[0046] ディレクタ復旧処理部 130は、ディレクタ 200— 200の中にダウンしたディレクタが
1 n
ある場合に、ダウンしたディレクタが復旧したカゝ否かを監視し、ディレクタが復旧した 際に復旧処理を行う処理部である。
[0047] 具体的には、このディレクタ復旧処理部 130は、復旧したディレクタに対してコミット 処理が行われて 、な 、未解決トランザクションの問合せを行 、、未解決トランザクショ ンがある場合には、トランザクション結果決定部 150を用いてその未解決トランザクシ ヨンに対して行うべき処理を決定し、決定した処理を復旧したディレクタに指示する。
[0048] このディレクタ復旧処理部 130力 復旧したディレクタに対してコミット処理が行われ て 、な 、未解決トランザクションの問合せを行 、、未解決トランザクションがある場合 には、トランザクション結果決定部 150を用いてその未解決トランザクションに対して 行うべき処理を決定し、決定した処理を復旧したディレクタに指示することによって、 コミット処理の際にダウンしたディレクタがある場合にもデータベース間の整合性を保 証することができる。
[0049] すなわち、応答処理部 120がいずれかのディレクタ力 応答があった場合に直ちに アプリケーションに対してコミットの成功を通知し、残りのディレクタにコミット処理要求 受信後コンダクタ 100への応答前にダウンしたディレクタがある場合にも、そのディレ クタが復旧後コミット処理を行うことができ、データベース間の整合性を保証すること ができる。
[0050] コンダクタ復旧処理部 140は、コンダクタ 100がダウンして復旧した際に、復旧処理 を行う処理部である。このコンダクタ復旧処理部 140は、復旧処理の一部として、未 解決トランザクションの処理を行う。
[0051] 具体的には、このコンダクタ復旧処理部 140は、全てのディレクタ 200— 200に対
1 n して未解決トランザクションの問合せを行 、、あるディレクタが未解決トランザクション があることを応答した場合には、トランザクション結果決定部 150を用いてその未解決 トランザクションに対して行うべき処理を決定し、決定した処理を未解決トランザクショ ンを応答したディレクタに指示する。
[0052] このコンダクタ復旧処理部 140力 復旧処理の一部として、全てのディレクタ 200
1 一 200に対して未解決トランザクションの問合せを行い、あるディレクタが未解決トラ ンザクシヨンがあることを応答した場合には、トランザクション結果決定部 150を用い てその未解決トランザクションに対して行うべき処理を決定し、決定した処理を未解決 トランザクションを応答したディレクタに指示することによって、ディレクタ 200— 200
1 n の一部にコミット要求を送信してコンダクタ 100がダウンした場合にも、データベース 間の整合性を保証することができる。
[0053] トランザクション結果決定部 150は、ディレクタ復旧処理部 130およびコンダクタ復 旧処理部 140の指示にしたがって、未解決トランザクションに対して行うべき処理を 決定する処理部である。
[0054] 具体的には、このトランザクション結果決定部 150は、未解決トランザクションに対 するコミット結果を他のディレクタに問い合わせ、他のディレクタのコミット結果に基づ いて未解決トランザクションに対して行うべき処理を決定する。
[0055] すなわち、このトランザクション結果決定部 150は、未解決トランザクションに対して 他のディレクタがコミット処理を行った場合には、未解決トランザクションに対して行う べき処理をコミット処理に決定し、未解決トランザクションに対して他のディレクタが口 ールバックを行った場合には、未解決トランザクションに対して行うべき処理をロール バックに決定する。
[0056] 通信部 160は、アプリケーションを実行するコンピュータやディレクタ 200— 200な
1 n どとネットワーク 40を介して通信する処理部であり、アプリケーションからのコミット要 求やディレクタ 200— 200力もの応答などを受信し、アプリケーションへのコミット結
1 n
果の応答やディレクタ 200— 200へのコミット処理要求などを送信する。
1 n
[0057] ディレクタ 200 200は、分散トランザクションを処理するためにアクセスする必要
1 n
がある複数のデータベースのそれぞれを管理する装置であり、コンダクタ 100からトラ ンザクシヨン処理要求を受け付けてトランザクションを分散処理する。なお、ディレクタ 200一 200はいずれも同様の構成を有するので、ここではディレクタ 200を例にと
1 n 1 つて説明する。
[0058] ディレクタ 200は、トランザクション処理部 210と、未解決トランザクション応答部 22
1
0と、通信部 230とを有する。
[0059] トランザクション処理部 210は、コンダクタ 100からトランザクション処理要求を受け 付けてトランザクションを分散処理し、レコード形式でデータを格納するデータフアイ ル 10を更新する処理部である。
[0060] また、このトランザクション処理部 210は、データファイル 10のレコードの格納位置 を記憶する RowIDファイル 20およびトランザクションログを記憶するログファイル 30 を更新する。
[0061] 図 2は、各レコードに対応して RowIDファイル 20に作成されるエントリのデータ構造 の一例を示す図である。同図に示すように、このエントリには、レコード格納位置とトラ ンザクシヨン IDとが含まれる。
[0062] レコード格納位置は、データファイル 10のレコードの格納位置を示す。トランザクシ ヨン IDは、このエントリに対応するレコードの追加 '削除'更新を最後に行ったトランザ クシヨンを識別する識別子であり、トランザクションの処理が完了するとトランザクション 処理部 210によって更新される。
[0063] 図 3は、ログファイル 30に含まれる未解決トランザクション一覧のデータ構造の一例 を示す図である。同図に示すように、この未解決トランザクション一覧には、コミット処 理が行われて ヽな ヽ m個のトランザクションの識別子であるトランザクション ID
1—トラ ンザクシヨン IDが記憶されている。
m
[0064] 未解決トランザクション応答部 220は、コンダクタ 100からの未解決トランザクション の問合せに対してログファイル 30の未解決トランザクション一覧に記憶されたトランザ クション IDをコンダクタ 100に応答する処理部である。
[0065] この未解決トランザクション応答部 220が、コンダクタ 100からの問合せに対して未 解決トランザクションを応答することによって、コンダクタ 100は、このディレクタ 200ま
1 たはコンダクタ 100自身の復旧処理において処理が必要な未解決トランザクションを 特定することができる。 [0066] また、この未解決トランザクション応答部 220は、コンダクタ 100からの他のディレク タの未解決トランザクションに関するコミット結果の問合せに対して、ログファイル 30の 未解決トランザクション一覧および RowIDファイル 20を用いてコンダクタ 100に応答 する。
[0067] 具体的には、この未解決トランザクション応答部 220は、コンダクタ 100から未解決 トランザクションのトランザクション IDを受け取り、そのトランザクション IDが未解決トラ ンザクシヨン一覧にあればコミット未完了であることを応答し、未解決トランザクション 一覧になければ RowIDファイル 20内にあるか否かを調べ、 RowIDファイル 20内に ある場合には、トランザクションがコミットされているのでコミット完了を応答し、 RowID ファイル 20内にない場合には、トランザクションがコミットされていないのでコミット未 完了を応答する。
[0068] この未解決トランザクション応答部 220力 コンダクタ 100からの他のディレクタの未 解決トランザクションに関するコミット結果の問合せに対して、ログファイル 30の未解 決トランザクション一覧および RowIDファイル 20を用いてコミットが完了したか否かを コンダクタ 100に応答することによって、コンダクタ 100は、他のディレクタの未解決ト ランザクシヨンに対する処理を決定することができる。
[0069] 通信部 230は、コンダクタ 100などとネットワーク 40を介して通信する処理部であり 、例えば、コンダクタ 100からコミット処理要求や未解決トランザクションの問合せを受 信し、コンダクタ 100へコミット結果や未解決トランザクションのトランザクション IDを送 信する。
[0070] 次に、コンダクタ 100によるコミット処理の処理手順について説明する。図 4は、コン ダクタ 100によるコミット処理の処理手順を示すフローチャートである。同図に示すよう に、このコンダクタ 100は、要求処理部 110がアプリケーションからコミット要求を受信 し (ステップ S101)、関連するディレクタ群にコミット処理要求を送信する(ステップ S1 02)。
[0071] そして、 、ずれかのディレクタにコミット処理要求を送信できた力否かを判定し (ステ ップ S 103)、いずれのディレクタにもコミット処理要求を送信できなかった場合には、 全ディレクタがダウンしている場合であるので、アプリケーションにコミットの失敗を通 知する(ステップ SI 08)。
[0072] 一方、 、ずれかのディレクタにコミット処理要求を送信できた場合には、応答処理部 120力 いずれかのディレクタ力も応答があると (ステップ S 104、肯定)、アプリケーシ ヨンへコミットの成功を通知し (ステップ S 105)、 V、ずれのディレクタからも応答がな!ヽ 場合には、タイムアウトである力否かを判定する (ステップ S106)。
[0073] その結果、タイムアウトでない場合には、引き続きディレクタ力もの応答を待ち、タイ ムアウトの場合には、コミット処理要求を受け付けた全てのディレクタが要求受付後に ダウンした場合であり、各ディレクタでコミット処理がどこまで行われたかわからな!ヽの で、アプリケーションへコミット結果が不明であることを通知する (ステップ S 107)。
[0074] このように、コンダクタ 100がディレクタにコミット処理要求を送信し、いずれかのディ レクタカ 応答があると直ちにアプリケーションにコミットの成功を通知するので、ァプ リケーシヨンからのコミット要求を高速に処理することができる。
[0075] 次に、図 1に示したディレクタ復旧処理部 130によるディレクタ復旧処理の処理手順 について説明する。図 5は、図 1に示したディレクタ復旧処理部 130によるディレクタ 復旧処理の処理手順を示すフローチャートである。
[0076] 同図に示すように、このディレクタ復旧処理部 130は、ダウンしたディレクタがある場 合に、ダウンしたディレクタに定期的に接続を試行し (ステップ S201)、接続できると、 未解決トランザクションの問合せを行う(ステップ S202)。
[0077] そして、未解決トランザクションがある力否かを判定し (ステップ S203)、未解決トラ ンザクシヨンがある場合には、未解決トランザクションを一つ選択し (ステップ S204)、 選択した未解決トランザクションに対して行うべき処理を決定するトランザクション結果 決定処理を行う(ステップ S 205)。
[0078] そして、未解決トランザクションに対して行うべき処理が決定した力否力、すなわち、 コミットまたはロールバックが決定したか否かを判定し (ステップ S206)、コミット力ロー ルバックが決定した場合には、復旧したディレクタに対して決定結果に基づいて未解 決トランザクションを処理するように指示し (ステップ S207)、ステップ S203に戻って 次の未解決トランザクションの処理に移る。
[0079] 一方、コミットかロールバックかが不明な場合には、復旧したディレクタにその未解 決トランザクションについては指示することなぐステップ S203に戻って次の未解決ト ランザクシヨンの処理に移る。
[0080] このように、このディレクタ復旧処理部 130が、復旧したディレクタの未解決トランザ クシヨンの処理をトランザクション結果決定処理によって決定し、決定した処理を復旧 したディレクタに指示することによって、コミット処理前にダウンしたディレクタのコミット 処理を復旧後に正しく行うことができる。
[0081] 次に、図 1に示したコンダクタ復旧処理部 140によるコミット復旧処理の処理手順に ついて説明する。図 6は、図 1に示したコンダクタ復旧処理部 140によるコミット復旧 処理の処理手順を示すフローチャートである。
[0082] 同図に示すように、このコンダクタ復旧処理部 140は、ダウン力も復旧後にディレク タを一つ選択し (ステップ S301)、未解決トランザクションの問合せを行う(ステップ S3 02)。
[0083] そして、未解決トランザクションがある力否かを判定し (ステップ S303)、未解決トラ ンザクシヨンがな 、場合には、全ディレクタを処理した力否かを判定し (ステップ S304 )、全ディレクタを処理していない場合には、ステップ S301に戻って次のディレクタの 処理に移り、全ディレクタを処理した場合には、処理を終了する。
[0084] 一方、未解決トランザクションがある場合には、未解決トランザクションを一つ選択し
(ステップ S305)、選択した未解決トランザクションに対して行うべき処理を決定するト ランザクシヨン結果決定処理を行う(ステップ S306)。
[0085] そして、未解決トランザクションに対して行うべき処理が決定した力否力、すなわち、 コミットまたはロールバックが決定したか否かを判定し (ステップ S307)、コミット力ロー ルバックが決定した場合には、選択して!/、るディレクタに対して決定結果に基づ!/、て 未解決トランザクションを処理するように指示し (ステップ S308)、ステップ S303に戻 つて次の未解決トランザクションの処理に移る。
[0086] 一方、コミットかロールバックかが不明な場合には、選択しているディレクタにその未 解決トランザクションについては指示することなぐステップ S303に戻って次の未解 決トランザクションの処理に移る。
[0087] このように、このコンダクタ復旧処理部 140がディレクタに未解決トランザクションの 問合せを行 、、未解決トランザクションに対して行うべき処理をトランザクション結果決 定処理によって決定し、決定した処理をディレクタに指示することによって、コミット要 求を一部のディレクタに送信した後にコンダクタ 100がダウンした場合にも、復旧後に 残りのディレクタのコミット処理を正しく行うことができる。
[0088] 次に、図 1に示したトランザクション結果決定部 150によるトランザクション結果決定 処理の処理手順について説明する。図 7は、図 1に示したトランザクション結果決定 部 150によるトランザクション結果決定処理の処理手順を示すフローチャートである。 なお、このトランザクション結果決定処理は、図 5のステップ S205の処理および図 6 のステップ S306の処理に対応する。
[0089] 図 7に示すように、このトランザクション結果決定部 150は、未解決トランザクション の状態が未完了である力否かを判定し (ステップ S401)、未解決トランザクションの状 態が未完了である場合には、結果を未確定として処理を終了する (ステップ S412)。
[0090] 一方、未解決トランザクションの状態が未完了でない場合には、ダウンディレクタの 数を数えるための変数としてダウンディレクタ数を「0」に初期化し (ステップ S402)、 ディレクタを一つ選択する(ステップ S403)。
[0091] そして、選択したディレクタに対して未解決トランザクションの処理結果の問合せを 行 ヽ(ステップ S404)、ディレクタがダウンして!/、るか否かを判定する(ステップ S405
) o
[0092] その結果、ディレクタがダウンして!/ヽな ヽ場合には、未解決トランザクションの処理 結果の問合せに対する応答がコミットである力否かを判定し (ステップ S406)、コミット である場合には、結果をコミットとして処理を終了する (ステップ S407)。
[0093] 一方、未解決トランザクションの処理結果の問合せに対する応答がコミットでない場 合には、未解決トランザクションの処理結果は不明であり、他のディレクタに問い合わ せる必要があるので、ステップ S409に進んで全ディレクタに対して問い合わせたか 否かを判定する。
[0094] また、ディレクタがダウンしている場合には、ダウンディレクタ数に「1」をカロえ (ステツ プ S408)、全ディレクタに対して問い合わせたか否かを判定する(ステップ S409)。
[0095] その結果、全ディレクタに対して問い合わせていない場合には、ステップ S403に戻 つて次のディレクタを選択し、全ディレクタに対して問い合わせた場合には、ダウンデ ィレクタ数が「0」であるか否かを判定する(ステップ S410)。
[0096] そして、ダウンディレクタ数が「0」である場合には、全てのディレクタがコミットを行つ ていないので、結果をロールバックとして処理を終了し (ステップ S411)、ダウンディ レクタ数が「0」でな 、場合には、ダウンして 、るディレクタによる未解決トランザクショ ンの処理結果が不明であるので、結果を未確定として処理を終了する (ステップ S41 2)。
[0097] このように、このトランザクション結果決定部 150が、未解決トランザクションのコミット 結果をディレクタに順に問い合わせ、コミットしたディレクタがある場合には、未解決ト ランザクシヨンの結果をコミットと決定し、全ディレクタがコミットしな力つた場合には、 未解決トランザクションの結果をロールバックと決定することによって、コンダクタ 100 によるトランザクション処理結果のログ記録をなくすことができる。
[0098] 次に、 2台のディレクタが分散トランザクションを処理する場合に、ディレクタがダウン する各タイミングに対応するデータベース整合性維持動作について説明する。図 8は 、 2台のディレクタが分散トランザクションを処理する場合に、ディレクタがダウンする 各タイミングに対応するデータベース整合性維持動作を示す図である。
[0099] 同図に示すように、 2台のディレクタ Dおよび Dがいずれもダウンしない場合には、
1 2
コミット要求に対するアプリケーションへの応答はコミット成功となり、トランザクションの 結果はコミットとなる。また、データベース間の整合性を維持するための動作は何も必 要ない。
[0100] また、ディレクタ Dがダウンせずディレクタ Dがダウンした場合には、ディレクタ Dが
1 2 2 ダウンしたタイミングに関係なぐコミット要求に対するアプリケーションへの応答はコミ ット成功となり、トランザクションの結果はコミットとなる。
[0101] ただし、 Dがコミット指示を受け付ける前またはコミット処理中にダウンした場合には
2
、 Dは再起動後、コンダクタ 100を通じて Dでのコミット完了を知り、コミットする。また
2 1
、 Dがコミット応答前にダウンした場合には、データベース間の整合性を維持するた
2
めの動作は何も必要な!/、。
[0102] また、ディレクタ Dがコミット指示を受け付ける前にダウンし、ディレクタ Dもコミット指 示を受け付ける前にダウンした場合には、コミット要求に対するアプリケーションへの 応答はコミット失敗となり、トランザクションの結果はロールバックとなり、 Dおよび Dは
1 2 再起動後、コンダクタ 100を通じてコミットが完了したディレクタがな力つたことを知り、 ローノレノ ックする。
[0103] また、ディレクタ Dがコミット指示を受け付ける前にダウンし、ディレクタ D力コミット
1 2 処理中にダウンした場合には、コミット要求に対するアプリケーションへの応答は不明 となり、トランザクションの結果はロールバックとなり、 Dおよび Dは再起動後、コンダ
1 2
クタ 100を通じてコミットが完了したディレクタがなかったことを知り、ロールバックする [0104] また、ディレクタ Dがコミット指示を受け付ける前にダウンし、ディレクタ D力コミット
1 2 応答前にダウンした場合には、コミット要求に対するアプリケーションへの応答は不明 となり、トランザクションの結果はコミットとなり、 Dは再起動後、コンダクタ 100を通じ
1
て Dでのコミット完了を知り、コミットする。
2
[0105] また、ディレクタ D力コミット処理中にダウンし、ディレクタ Dもコミット処理中にダウ
1 2
ンした場合には、コミット要求に対するアプリケーションへの応答は不明となり、トラン ザクシヨンの結果はロールバックとなり、 Dおよび Dは再起動後、コンダクタ 100を通
1 2
じてコミットが完了したディレクタがなかったことを知り、ロールバックする。
[0106] また、ディレクタ Dがコミット処理中にダウンし、ディレクタ Dがコミット応答前にダウ
1 2
ンした場合には、コミット要求に対するアプリケーションへの応答は不明となり、トラン ザクシヨンの結果はコミットとなり、 Dは再起動後、コンダクタ 100を通じて Dでのコミ
1 2 ット完了を知り、コミットする。
[0107] また、ディレクタ Dがコミット応答前にダウンし、ディレクタ Dもコミット応答前にダウ
1 2
ンした場合には、コミット要求に対するアプリケーションへの応答は不明となり、トラン ザクシヨンの結果はコミットとなり、データベース間の整合性を維持するための動作は 何も必要ない。
[0108] 上述してきたように、本実施例では、アプリケーション力ものコミット要求に対して関 連するディレクタに要求処理部 110がコミット処理要求を送信し、応答処理部 120が いずれかのディレクタ力 応答を受け取った場合にアプリケーションにコミットの成功 を通知し、ディレクタがダウンして未解決トランザクションがある場合には、ディレクタ が復旧した際に、ディレクタ復旧処理部 130が他のディレクタによる未解決トランザク シヨンの処理結果に基づいて未解決トランザクションの処理を復旧したディレクタに指 示することとしたので、 1フェーズコミットによってデータベース間の整合性を維持し、 もってコミット処理を高速ィ匕することができる。
[0109] また、ディレクタにコミット処理要求を送信中にコンダクタ 100がダウンして一部のデ ィレクタにコミット処理要求が送信できな力つた場合には、コンダクタ復旧処理部 140 が復旧後に各ディレクタに対して未解決トランザクションの問合せを行 ヽ、ディレクタ が応答した未解決トランザクションに対する他のディレクタの処理結果に基づいて未 解決トランザクションの処理を、応答したディレクタに指示することとしたので、 1フエ一 ズコミットによってデータベース間の整合性を維持し、もってコミット処理を高速ィ匕する ことができる。
[0110] また、本実施例では、コンダクタ 100は、ダウン力 復旧した際にディレクタに未解 決トランザクションを問合せることによって復旧処理を行うこととしたので、トランザクシ ヨンログを保有する必要がなく、システムの導入 ·運用の負担を軽減することができる
[0111] なお、本実施例では、コンダクタおよびディレクタについて説明した力 コンダクタや ディレクタが有する構成をソフトウェアによって実現することで、同様の機能を有する コンダクタプログラムやディレクタプログラムを得ることができる。そこで、これらのコン ダクタプログラムやディレクタプログラムを実行するコンピュータについて説明する。
[0112] 図 9は、本実施例に係るコンダクタプログラムおよびディレクタプログラムを実行する コンピュータを示す図である。なお、ここでは、コンダクタプログラムとディレクタプログ ラムを一つのコンピュータで実行する場合について説明する力 コンダクタプログラム とディレクタプログラムを別のコンピュータで実行することもできる。また、アプリケーシ ヨンとコンダクタプログラムを一つのコンピュータで実行することもできる。
[0113] 同図に示すように、このコンピュータ 300は、 HDD310と、 RAM320と、 ROM330 と、 CPU340と、 LANインタフェース 350と、 I/Oインタフェース 360とを有する。
[0114] HDD310は、コンダクタプログラム 311およびディレクタプログラム 312を記憶する 記憶装置であり、ディレクタプログラム 312が使用するデータファイル 10、 RowIDファ ィル 20およびログファイル 30も記憶する。
[0115] RAM320は、 HDD310から読み出されたコンダクタプログラム 311およびディレク タプログラム 312やプログラムの実行途中結果などを記憶するメモリであり、 ROM33
0は、定数などを記憶した読み出し専用メモリである。
[0116] CPU340は、 RAM320からコンダクタプログラム 311およびディレクタプログラム 3
12を読み出し、コンダクタプロセス 341およびディレクタプロセス 342として実行する 処理装置である。
[0117] LANインタフェース 350は、 LAN (ネットワーク)と接続するためのインタフェースで あり、 IZOインタフェース 360は、キーボードやマウスなどの入力装置および表示装 置を接続するインタフェースである。
[0118] そして、このコンピュータ 300において実行されるコンダクタプログラム 311およびデ ィレクタプログラム 312は、フロッピィディスク(FD)、 CD— ROM、 DVDディスク、光磁 気ディスク、 ICカードなどの可搬型記憶媒体に記憶され、これらの記憶媒体力も読み 出されてコンピュータ 300にインストールされる。
[0119] あるいは、コンダクタプログラム 311およびディレクタプログラム 312は、 LANインタ フェース 350を介して接続された他のコンピュータのデータベースなどに記憶され、 データベースなどから読み出されてコンピュータ 300にインストールされる。そして、ィ ンストールされたコンダクタプログラム 311およびディレクタプログラム 312は、 HDD3 10に記憶される。
産業上の利用可能性
[0120] 以上のように、本発明に係る分散トランザクション処理プログラム、分散トランザクシ ヨン処理方法および分散トランザクション処理装置は、分散トランザクションシステムに 有用であり、特に、コミット処理を高速ィ匕したい場合に適している。

Claims

請求の範囲
[1] 装置自身の故障以外ではコミット処理要求に対して必ずコミット処理を行って応答 する複数の処理装置にアプリケーション力 受け付けたトランザクションの分散処理を 指示する分散トランザクション処理プログラムであって、
前記アプリケーションからのコミット要求に対して複数の処理装置にコミット処理を要 求するコミット要求手順と、
前記コミット要求手順により要求したコミット処理に対していずれかの処理装置から 応答があった場合に前記アプリケーションに対してコミットの成功を応答するコミット応 答手順と、
前記コミット要求手順により要求したコミット処理に対して故障に起因して応答を行う ことができな力つた処理装置である故障処理装置が故障力 復旧した際に、該応答 が行われなかったトランザクションである未解決トランザクションの処理について他の 処理装置の処理結果に基づいて該故障処理装置に対して指示する復旧指示手順と をコンピュータに実行させることを特徴とする分散トランザクション処理プログラム。
[2] 前記復旧指示手順は、前記故障処理装置が復旧したか否かを判定する復旧判定 手順と、
前記復旧判定手順により故障処理装置が復旧したと判定された場合に、故障処理 装置の未解決トランザクションの処理結果にっ 、て他の処理装置に問合せを行 、、 問合せ結果に基づいて未解決トランザクションに対する処理を故障処理装置に要求 する処理装置復旧処理手順とを、
コンピュータに実行させることを特徴とする請求項 1に記載の分散トランザクション処 理プログラム。
[3] 前記復旧判定手順は、前記故障処理装置に対して定期的に接続を確認することに よって該故障処理装置が復旧したか否かを判定することを特徴とする請求項 2に記 載の分散トランザクション処理プログラム。
[4] 自装置の故障からの復旧時に処理装置に対して未解決トランザクションを問い合わ せる未解決問合せを行!ヽ、該未解決問合せに対して処理装置から応答された未解 決トランザクションの処理結果について他の処理装置に問い合わせる処理結果問合 せを行う未解決トランザクション処理結果問合せ手順と、
前記未解決トランザクション処理結果問合せ手順による処理結果問合せに対する 応答結果に基づいて該未解決トランザクションに対する処理を未解決問合せに対し て未解決トランザクションを応答した処理装置に要求する自装置復旧処理手順とを、 さらにコンピュータに実行させることを特徴とする請求項 1、 2または 3に記載の分散 トランザクション処理プログラム。
[5] 前記コミット要求手順は、コミット処理の要求がいずれの処理装置にも受け付けられ なカゝつた場合に、前記アプリケーションに対してコミットの失敗を応答することを特徴と する請求項 1に記載の分散トランザクション処理プログラム。
[6] 前記コミット応答手順は、前記コミット要求手順により要求したコミット処理に対して いずれの処理装置からも応答がな力つた場合には、前記アプリケーションにコミット結 果を不明と応答することを特徴とする請求項 1に記載の分散トランザクション処理プロ グラム。
[7] 装置自身の故障以外ではコミット処理要求に対して必ずコミット処理を行って応答 する複数の処理装置にアプリケーション力 受け付けたトランザクションの分散処理を 指示する分散トランザクション処理方法であって、
前記アプリケーションからのコミット要求に対して複数の処理装置にコミット処理を要 求するコミット要求工程と、
前記コミット要求工程により要求したコミット処理に対していずれかの処理装置から 応答があった場合に前記アプリケーションに対してコミットの成功を応答するコミット応 答工程と、
前記コミット要求工程により要求したコミット処理に対して故障に起因して応答を行う ことができな力つた処理装置である故障処理装置が故障力 復旧した際に、該応答 が行われなかったトランザクションである未解決トランザクションの処理について他の 処理装置の処理結果に基づいて該故障処理装置に対して指示する復旧指示工程と を含んだことを特徴とする分散トランザクション処理方法。
[8] 装置自身の故障以外ではコミット処理要求に対して必ずコミット処理を行って応答 する複数の処理装置にアプリケーション力 受け付けたトランザクションの分散処理を 指示する分散トランザクション処理装置であって、
前記アプリケーションからのコミット要求に対して複数の処理装置にコミット処理を要 求するコミット要求手段と、
前記コミット要求手段により要求したコミット処理に対していずれかの処理装置から 応答があった場合に前記アプリケーションに対してコミットの成功を応答するコミット応 答手段と、
前記コミット要求手段により要求したコミット処理に対して故障に起因して応答を行う ことができな力つた処理装置である故障処理装置が故障力 復旧した際に、該応答 が行われなかったトランザクションである未解決トランザクションの処理について他の 処理装置の処理結果に基づいて該故障処理装置に対して指示する復旧指示手段と を備えたことを特徴とする分散トランザクション処理装置。
[9] 一つのトランザクションを分散処理する複数の処理装置と、アプリケーションからトラ ンザクシヨン処理要求を受け付けて該複数の処理装置に分散処理を要求するトラン ザクシヨン管理装置とから構成される分散トランザクション処理装置であって、 前記トランザクション管理装置は、
前記アプリケーションからのコミット要求に対して複数の処理装置にコミット処理を要 求するコミット要求手段と、
前記コミット要求手段により要求したコミット処理に対していずれかの処理装置から 応答があった場合に前記アプリケーションに対してコミットの成功を応答するコミット応 答手段と、
前記コミット要求手段により要求したコミット処理に対して故障に起因して応答を行う ことができな力つた処理装置である故障処理装置が故障力 復旧した際に、該応答 が行われなかったトランザクションである未解決トランザクションの処理について他の 処理装置の処理結果に基づいて該故障処理装置に対して指示する復旧指示手段と 、を備え、 前記処理装置は、装置自身の故障以外では前記トランザクション管理装置からのコ ミット処理要求に対して必ずコミット処理を行って該トランザクション管理装置に応答 することができるコミット処理手段と、
故障力 復旧した際に、前記トランザクション管理装置からの指示に基づいて前記 未解決トランザクションの処理を行う復旧処理手段と、
を備えたことを特徴とする分散トランザクション処理装置。
一つのトランザクションを分散処理する複数の処理装置と、アプリケーションからトラ ンザクシヨン処理要求を受け付けて該複数の処理装置に分散処理を要求するトラン ザクシヨン管理装置とから構成される分散トランザクション処理装置のコミット処理方 法であって、
前記トランザクション管理装置が前記アプリケーション力 のコミット要求に対して複 数の処理装置にコミット処理を要求するコミット要求工程と、
前記処理装置が装置自身の故障以外では前記トランザクション管理装置からのコミ ット処理要求に対して必ずコミット処理を行って該トランザクション管理装置に応答す るコミット処理工程と、
前記コミット要求工程により要求したコミット処理に対して、前記トランザクション管理 装置が、 V、ずれかの処理装置力 応答があった場合に前記アプリケーションに対し てコミットの成功を応答するコミット応答工程と、
前記コミット要求工程により要求したコミット処理に対して故障に起因して応答を行う ことができな力つた処理装置である故障処理装置が故障力も復旧した際に、前記トラ ンザクシヨン管理装置力 該応答が行われな力つたトランザクションである未解決トラ ンザクシヨンの処理にっ 、て他の処理装置の処理結果に基づ 、て該故障処理装置 に対して指示する復旧指示工程と、
故障力 復旧した際に、前記故障処理装置が、前記トランザクション管理装置から の指示に基づいて前記未解決トランザクションの処理を行う復旧処理工程と、 を含んだことを特徴とする分散トランザクション処理方法。
PCT/JP2004/017733 2004-11-29 2004-11-29 分散トランザクション処理方法、装置、及びプログラム WO2006057061A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2006546521A JP4500318B2 (ja) 2004-11-29 2004-11-29 分散トランザクション処理方法、装置、及びプログラム
PCT/JP2004/017733 WO2006057061A1 (ja) 2004-11-29 2004-11-29 分散トランザクション処理方法、装置、及びプログラム
US11/807,334 US7836338B2 (en) 2004-11-29 2007-05-25 Distributed transaction processing method, distributed transaction processing system, transaction management device, and computer product

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2004/017733 WO2006057061A1 (ja) 2004-11-29 2004-11-29 分散トランザクション処理方法、装置、及びプログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/807,334 Continuation US7836338B2 (en) 2004-11-29 2007-05-25 Distributed transaction processing method, distributed transaction processing system, transaction management device, and computer product

Publications (1)

Publication Number Publication Date
WO2006057061A1 true WO2006057061A1 (ja) 2006-06-01

Family

ID=36497810

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/017733 WO2006057061A1 (ja) 2004-11-29 2004-11-29 分散トランザクション処理方法、装置、及びプログラム

Country Status (3)

Country Link
US (1) US7836338B2 (ja)
JP (1) JP4500318B2 (ja)
WO (1) WO2006057061A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009175854A (ja) * 2008-01-22 2009-08-06 Fujitsu Ltd データ整合性を確保するためのプログラム、方法及びコンピュータ・システム
JP2012022379A (ja) * 2010-07-12 2012-02-02 Nippon Telegr & Teleph Corp <Ntt> 分散トランザクション処理システム、装置、方法およびプログラム
WO2015186219A1 (ja) * 2014-06-05 2015-12-10 株式会社日立製作所 分散処理システム及びその運用方法

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008070803A1 (en) 2006-12-06 2008-06-12 Fusion Multisystems, Inc. (Dba Fusion-Io) Apparatus, system, and method for managing data from a requesting device with an empty data token directive
US9280771B2 (en) * 2009-02-13 2016-03-08 International Business Machines Corporation Secure personal information profile
US8266126B2 (en) * 2010-03-24 2012-09-11 Matrixx Software, Inc. System with multiple conditional commit databases
WO2011143628A2 (en) 2010-05-13 2011-11-17 Fusion-Io, Inc. Apparatus, system, and method for conditional and atomic storage operations
US20110320530A1 (en) 2010-06-29 2011-12-29 International Business Machines Corporation Method for processing a unit of work
EP2598996B1 (en) 2010-07-28 2019-07-10 SanDisk Technologies LLC Apparatus, system, and method for conditional and atomic storage operations
US9710865B1 (en) * 2011-08-15 2017-07-18 Amazon Technologies, Inc. Coordinating distributed order execution
US9465648B2 (en) * 2012-07-31 2016-10-11 Hewlett Packard Enterprise Development Lp Distributed transaction processing through commit messages sent to a downstream neighbor
US11003621B2 (en) 2015-11-11 2021-05-11 International Business Machines Corporation Scalable enterprise content management
CN110196759B (zh) * 2018-06-20 2022-12-06 腾讯科技(深圳)有限公司 分布式事务处理方法和装置、存储介质及电子装置
US11501295B2 (en) * 2019-07-24 2022-11-15 Advanced New Technologies Co., Ltd. Object distribution processing
US11409618B2 (en) 2020-09-14 2022-08-09 International Business Machines Corporation Transaction recovery

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0464146A (ja) * 1990-07-04 1992-02-28 Hitachi Ltd 分散システムにおけるコミットメント処理の最適化方式
JPH04229333A (ja) * 1990-05-16 1992-08-18 Internatl Business Mach Corp <Ibm> コミット手順の非同期的再同期化実行装置および方法
JPH06259397A (ja) * 1993-03-04 1994-09-16 Hitachi Ltd 分散トランザクション処理システム
JPH07262073A (ja) * 1994-03-18 1995-10-13 Fujitsu Ltd トランザクション続行方法ならびにそのためのサーバおよびリソースマネージャ
JPH10506742A (ja) * 1995-06-03 1998-06-30 インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン 経路指定ノードにおける同期化プロシージャ

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH077351B2 (ja) * 1989-09-06 1995-01-30 株式会社日立製作所 トランザクション処理の終了方法
JPH07210436A (ja) * 1994-01-10 1995-08-11 Hitachi Ltd 分散トランザクション処理システム
US5799305A (en) * 1995-11-02 1998-08-25 Informix Software, Inc. Method of commitment in a distributed database transaction
JP2000047986A (ja) * 1998-07-27 2000-02-18 Ntt Data Corp トランザクション処理システム
US6295610B1 (en) * 1998-09-17 2001-09-25 Oracle Corporation Recovering resources in parallel
US6510421B1 (en) * 1998-12-29 2003-01-21 Oracle Corporation Performing 2-phase commit with presumed prepare
US6772363B2 (en) * 2001-03-12 2004-08-03 Hewlett-Packard Development Company, L.P. Fast failover database tier in a multi-tier transaction processing system
KR20030056540A (ko) * 2001-12-28 2003-07-04 한국전자통신연구원 데이터베이스 관리 시스템에서 시스템 고장에 대비한 파일삭제 및 회복 방법
US7707181B2 (en) * 2003-02-19 2010-04-27 Microsoft Corporation System and method of distributing replication commands
JP4229333B2 (ja) 2005-07-06 2009-02-25 一方社油脂工業株式会社 アルデヒド類捕集剤及びこれを用いた木質板の製造方法
US7519859B2 (en) * 2005-08-30 2009-04-14 International Business Machines Corporation Fault recovery for transaction server

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04229333A (ja) * 1990-05-16 1992-08-18 Internatl Business Mach Corp <Ibm> コミット手順の非同期的再同期化実行装置および方法
JPH0464146A (ja) * 1990-07-04 1992-02-28 Hitachi Ltd 分散システムにおけるコミットメント処理の最適化方式
JPH06259397A (ja) * 1993-03-04 1994-09-16 Hitachi Ltd 分散トランザクション処理システム
JPH07262073A (ja) * 1994-03-18 1995-10-13 Fujitsu Ltd トランザクション続行方法ならびにそのためのサーバおよびリソースマネージャ
JPH10506742A (ja) * 1995-06-03 1998-06-30 インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン 経路指定ノードにおける同期化プロシージャ

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009175854A (ja) * 2008-01-22 2009-08-06 Fujitsu Ltd データ整合性を確保するためのプログラム、方法及びコンピュータ・システム
JP2012022379A (ja) * 2010-07-12 2012-02-02 Nippon Telegr & Teleph Corp <Ntt> 分散トランザクション処理システム、装置、方法およびプログラム
WO2015186219A1 (ja) * 2014-06-05 2015-12-10 株式会社日立製作所 分散処理システム及びその運用方法

Also Published As

Publication number Publication date
JP4500318B2 (ja) 2010-07-14
JPWO2006057061A1 (ja) 2008-06-05
US20080005220A1 (en) 2008-01-03
US7836338B2 (en) 2010-11-16

Similar Documents

Publication Publication Date Title
US7836338B2 (en) Distributed transaction processing method, distributed transaction processing system, transaction management device, and computer product
US7716373B2 (en) Method, apparatus, and computer product for updating software
US20070220323A1 (en) System and method for highly available data processing in cluster system
JP2003022258A (ja) サーバーのバックアップシステム
US7565383B2 (en) Application recovery
JP5729209B2 (ja) 情報処理装置、情報処理システムのテスト方法およびプログラム
US8504873B1 (en) Method and apparatus for providing in-memory checkpoint services within a distributed transaction
JP2013508884A (ja) 複製されたデータインスタンスのモニタリング
JPH10149296A (ja) サーバ・コンピュータ集約トポロジーを識別するための方法及び装置
JP4141875B2 (ja) リカバリ処理方法及びその実施システム並びにその処理プログラム
US11755364B2 (en) Transferral of process state and/or components in computing environments
WO2011076058A1 (zh) 分布式数据库升级的方法、升级处理装置及升级控制装置
JP2017187883A (ja) 情報処理装置、情報処理システム及び構成変更検証プログラム
WO2006057040A1 (ja) コンピュータ・システム及び情報処理方法
JP2006053728A (ja) 障害対処ルール伝播方法、障害復旧装置およびプログラム
JP4129353B2 (ja) 分散データ管理システム、分散データ管理方法及び分散データ管理プログラム
JP5418070B2 (ja) 業務操作支援方法及びコンピュータ装置
CN111324632A (zh) 利用客户端侧高速缓存的透明数据库会话恢复
CN115617917B (zh) 一种数据库集群多活控制的方法、装置、系统和设备
WO2010035480A1 (ja) 分散処理システム、分散処理方法およびプログラム
JP2008225933A (ja) パッチ同期化システム及びその方法並びにそれに用いる端末
JP5530810B2 (ja) スケールアウトシステムおよび方法ならびにプログラム
JP2004302743A (ja) 識別子対応関係認識プログラム、情報処理装置、および入出力装置共用システム
JPH0895932A (ja) 分散処理システムの系切り替え制御方法
JP3003759B2 (ja) ジョブ制御方式

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

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

Ref document number: 2006546521

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 11807334

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 11807334

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 04822453

Country of ref document: EP

Kind code of ref document: A1

WWW Wipo information: withdrawn in national office

Ref document number: 4822453

Country of ref document: EP