JP2012194951A - Transaction processing system and transaction processing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To resolve a problem of NFS and improve performance.SOLUTION: A transaction processing system includes a file client 1 for transmitting a request for respective predetermined operations, and a file agent 2 for transmitting a response result every time a request is received. The file agent 2 includes a communication control part 20 for generating a directory name by using a hash value of a transaction identifier, a file access control part 22 for registering a file that is a registration object in a file storage device 32 at the time of reception of a registration request, a provisional registration list storage part 25 for provisionally registering file information on a registration target at the time of reception of a registration request, and a file information control part 21 for storing the file information that is provisionally registered in a file information DB 31 at the time of reception of a commit request. The file access control part 22, the provisional registration list storage part 25, and the file information control part 21 delete file information corresponding to uncompleted transaction at the time of reception of a rollback request.

Description

  The present invention relates to a transaction processing system and a transaction processing method.

  The conventional transaction processing system (T101) adopts NAS (Network Attached Storage) as a storage destination of a file for storing data for the purpose of data transfer between application servers, data assurance, and operation management. Network File System) is used (for example, see Patent Document 1 below).

  NFS is a general-purpose file protocol, but is incompatible with the file access method unique to the transaction processing system (T101).

JP 2006-268588 A

  For the transaction processing system (T101), NFS has the following problems (1) to (4).

  (1) When a hard mount is used, the NFS client hangs up when the NFS server fails. Hang-up can be avoided by using soft mount. However, in the transaction processing system (T101), the file output function is confirmed as the successful completion of the file output function, so data write guarantee by hard mount is indispensable, and software without write guarantee The mount cannot be used.

  (2) There is an upper limit on the number of links in one directory. In the transaction processing system (T101), for the purpose of managing the disk arrangement, transaction commit, and obtaining file information at the time of failure recovery, the directory is divided into transaction units for each output destination and its subordinates. Yes. Even in a large-scale system, the number of output destinations is very acceptable, but if a large number of transactions are executed while the output destination is stopped due to a failure, the number of directories per transaction increases. Too much will not be able to output the file.

  (3) Redundancy of communication processing. For file access of the transaction processing system (T101), for example, in the case of data output, a series of operations including creation of a necessary directory, file opening, data writing, and file closing are determined. On the other hand, since the NFS performs communication between the NFS server and the client for each file access request (open, close, etc.) and checks the execution result, the next request is performed. Low performance.

  (4) Cash inefficiency. In the transaction processing system (T101), the files input by the transaction are read in order from the oldest one in order to maintain the order. On the other hand, the disk cache generally gives priority to frequently used files and the latest files. Therefore, the disk cache is not suitable for the transaction processing system (T101) that accesses the oldest file among the files that are equally accessed.

  The present invention has been made to solve the above-described problems, and an object of the present invention is to provide a transaction processing system and a transaction processing method capable of solving problems with NFS and improving performance.

  The transaction processing system of the present invention comprises: a file client that transmits a request in a predetermined operation unit; and a file agent that transmits a result for the request each time the request is received, and the file agent includes the request A communication control unit that generates a directory name using a hash value of a transaction identifier corresponding to the file, a file access control unit that registers a file to be registered in a file storage device when receiving a registration request as the request, and A temporary registration list storage unit that temporarily registers file information to be registered when a registration request is received, and a file information control that stores temporarily registered file information in the file information DB when a commit request is received as the request A file access control unit, the temporary registration List storage unit and the file information control unit, upon receiving the rollback request as the request to delete the file information corresponding to the uncompleted transaction.

  The transaction processing method of the present invention is a method for controlling a transaction processing system comprising: a file client that transmits a request in a predetermined unit of operation; and a file agent that transmits a result for the request each time the request is received. The file agent generates a directory name using a hash value of a transaction identifier corresponding to the request, and registers a file to be registered in the file storage device when receiving a registration request as the request. A step of temporarily registering file information to be registered when the registration request is received, and a step of storing temporarily registered file information in the file information DB when a commit request is received as the request. , A rollback request as the request When signal comprises a step of deleting the file information corresponding to the uncompleted transaction, the.

  According to the present invention, problems with NFS can be solved and performance can be improved.

It is a block diagram which illustrates the composition of the file protocol applicable to the transaction processing system in an embodiment. It is a figure which shows the data structure of a file information table. It is a flowchart for demonstrating operation | movement of the communication control part of a file agent. 10 is a flowchart for explaining a processing procedure of registration request processing B; 10 is a flowchart for explaining a processing procedure of acquisition request processing C; 10 is a flowchart for explaining a processing procedure of commit request processing D; 10 is a flowchart for explaining a processing procedure of rollback request processing E; 10 is a flowchart for explaining a processing procedure of list request processing F; It is a figure showing an example of the state at the time of a failure. It is a block diagram which illustrates the composition of a transaction processing system.

  DESCRIPTION OF EMBODIMENTS Hereinafter, preferred embodiments of a transaction processing system and a transaction processing method according to the present invention will be described with reference to the accompanying drawings.

  In this embodiment, NFS is replaced with a file protocol applicable to the transaction processing system (T101) as shown in FIG.

  As shown in FIG. 1, the file protocol includes a file client 1 and a file agent 2. The file client 1 operates according to instructions from the application. The file agent 2 operates according to a request from the file client 1.

  The file client 1 includes a communication control unit 10, a file registration unit 11, a file acquisition unit 12, a commit unit 13, a rollback unit 14, and a list acquisition unit 15.

  The file registration unit 11 requests the file agent 2 to register a file using the communication control unit 10.

  The file acquisition unit 12 requests the file agent 2 to acquire a file using the communication control unit 10.

  The commit unit 13 specifies a transaction identifier to the file agent 2 using the communication control unit 10 and requests a commit.

  The rollback unit 14 requests the rollback by specifying a transaction identifier to the file agent 2 using the communication control unit 10.

  The list acquisition unit 15 requests the file agent 2 to acquire a list using the communication control unit 10.

  The file agent 2 includes a communication control unit 20, a file information control unit 21, a file access control unit 22, and a cache control unit 23.

  The file information control unit 21 accesses the temporary registration list storage unit 25 and the file information DB 31 in accordance with instructions from the communication control unit 20.

  The file access control unit 22 accesses the file storage device 32 in accordance with instructions from the communication control unit 20.

  The cache control unit 23 accesses the cache storage unit 26 in accordance with an instruction from the communication control unit 20.

  The temporary registration list storage unit 25 and the file information DB 31 have a table structure shown in FIG. The file information table shown in FIG. 2 includes, for example, a destination, an output source, an output transaction identifier, a file name, an input transaction identifier, and a path as data items. The destination, output source, output transaction identifier, file name, and input transaction identifier are file information, and the path is generated from the file information.

  The temporary registration list storage unit 25 stores information on files that are registered before the application requests a commit. The stored file information is stored in the file information DB 31 by committing and is deleted from the temporary registration list storage unit 25 by rollback.

  The cache storage unit 26 stores the contents of the file.

  The file client 1 and the file agent 2 communicate with each other via a network with the communication control unit 10 and the communication control unit 20, respectively.

  The operation of the communication control unit 20 of the file agent 2 will be described with reference to FIG.

  First, the communication control unit 20 receives a request from the file client 1 (step S101), and determines the type of the received request (step S102).

  If it is determined in step S102 that the request is a “registration request”, a registration request process B described later is executed, and then the process proceeds to step S101.

  If it is determined in the request determination in step S102 that the request is an “acquisition request”, an acquisition request process C described later is executed, and then the process proceeds to step S101.

  If it is determined in the request determination in step S102 that the request is a “commit request”, a commit request process D described later is executed, and then the process proceeds to step S101.

  If it is determined in the request determination in step S102 that the request is a “rollback request”, a rollback request process E described later is executed, and then the process proceeds to step S101.

  If it is determined in the request determination in step S102 that the request is “list request”, a list request process F described later is executed, and then the process proceeds to step S101.

  With reference to FIG. 4, the processing procedure of the registration request processing B will be described.

  First, the communication control unit 20 issues a file registration request to the file access control unit 22 (step S201). As a result, the file access control unit 22 receives the file registration request, and creates and registers the file in the designated path in the file storage device 32.

  Here, when specifying the file path, the communication control unit 20 acquires a hash value based on the character string of the transaction identifier, and uses the hash value as a directory name instead of the transaction identifier. Conventionally, a directory is provided for each transaction identifier, and files are stored in the directory. On the other hand, in the present invention, a directory is provided for each transaction identifier having the same hash value, and the number of directories can be reduced by storing files in the directory.

  Subsequently, the communication control unit 20 issues a cache registration request to the cache control unit 23 (step S202).

  Subsequently, the communication control unit 20 determines the result of file registration by the file access control unit 22 (step S203).

  If the determination result is that the file registration is successful, the communication control unit 20 requests the file information control unit 21 to combine the file information acquired from the file client 1 and the generated file path, and request a temporary file information registration. (Step S205), and waits until the provisional registration is completed. Subsequently, the communication control unit 20 waits until the cache registration result is acquired (step S206), and transmits a response to the file client 1 (step S207).

  On the other hand, if the determination result in step S203 is that the file registration has failed, the communication control unit 20 waits until the cache registration result is acquired (step S206), and transmits a response to the file client 1 (step S207). ).

  With reference to FIG. 5, the processing procedure of the acquisition request processing C will be described.

  First, the communication control unit 20 requests the file information control unit 21 to register the input transaction identifier in the file information of the acquisition target file (step S301).

  Subsequently, the communication control unit 20 determines a result for the request in step S301 (step S302).

  If the determination result is registration failure, that is, the corresponding record does not exist, the communication control unit 20 transmits a response indicating that the file does not exist to the file client 1 (step S306).

  On the other hand, if the determination result in step S302 is that registration is successful, the communication control unit 20 issues a cache acquisition request to the cache control unit 23 (step S303).

  Subsequently, the communication control unit 20 determines a result for the cache acquisition request (step S304).

  If the determination result is acquisition success, the communication control unit 20 transmits a response including the cache contents as the contents of the acquisition target file to the file client 1 (step S306).

  On the other hand, if the determination result in step S304 is an acquisition failure, that is, the cache does not exist, the communication control unit 20 issues a file acquisition request to the file access control unit 22 (step S305). A response including the contents of the file is transmitted to the file client 1 (step S306).

  With reference to FIG. 6, the procedure of the commit request process D will be described.

  First, the communication control unit 20 acquires a list of file information having the input transaction identifier specified by the file client 1 from the file information control unit 21 (step S401).

  Subsequently, the communication control unit 20 requests the file access control unit 22 to delete all the files in the acquired list (step S402).

  Subsequently, the communication control unit 20 requests the file information control unit 21 to delete all records having the input transaction identifier specified by the file client 1 from the file information DB 31 (step S403).

  Subsequently, the communication control unit 20 sends the file information having the transaction identifier specified by the file client 1 out of the file information stored in the temporary registration list storage unit 25 to the file information control unit 21 as file information. A request is made to register in the DB 31 (step S404).

  Subsequently, the communication control unit 20 transmits a response to the file client 1 (step S405).

  With reference to FIG. 7, the processing procedure of the rollback request processing E will be described.

  First, the communication control unit 20 requests the file information control unit 21 to delete the file information having the input transaction identifier specified by the file client 1 from the file information DB 31 (step S501).

  Subsequently, the communication control unit 20 requests the file access control unit 22 to delete the file having the designated transaction identifier in the temporary registration list storage unit 25 from the file storage device 32 (step S502). ).

  Subsequently, the communication control unit 20 requests the file information control unit 21 to delete the file information having the transaction identifier specified by the file client 1 from the temporary registration list storage unit 25 (step S503).

  Subsequently, the communication control unit 20 transmits a response to the file client 1 (step S504).

  With reference to FIG. 8, the processing procedure of the list request processing F will be described.

  First, the communication control unit 20 requests the file information control unit 21 to acquire from the file information DB 31 file information that satisfies the conditions specified by the file client 1 (step S601).

  Subsequently, the communication control unit 20 transmits a response including the acquired file information to the file client 1 (step S602).

  Here, when the file agent 2 is restarted due to a failure, if the file information DB 31 is updated in the state shown in FIG. 9 when the failure occurs, the file information DB 31 is rolled back. After that, the file client 1 that has detected the abnormality of the file agent 2 performs recovery again by causing the commit unit 13 or the rollback unit 14 to function again according to the same processing or the situation.

  Next, a case where the above-described file protocol is applied to a transaction processing system will be described with reference to FIG.

  This transaction processing system is a system for inputting data from the external input device 4 and finally updating the databases DB-B8 and DB-C9.

  The application A7 inputs data from the external input device 4, and outputs the data to the application B7 or the application C7 according to the determined rule. The application B7 inputs the data from the application A7, updates the database DB-B8 according to the determined rule, or outputs the data to the application C7. The application C7 inputs data from the application A7 or the application B7, and updates the database DB-C9.

  The application A7 has a plurality of file clients A1. The application B7 has a plurality of file clients B1. The application C7 has a plurality of file clients C1.

  The file server 6 has a plurality of file agents A2, B2, and C2. Each file agent A 2, B 2, C 2 shares the file storage device 32.

  A plurality of file agents A2 exist and communicate with the file client A1 of the application A7. The file information DBA 31 is shared by a plurality of file agents A2.

  A plurality of file agents B2 exist and communicate with the file client B1 of the application B7. The file information DBB 31 is shared by a plurality of file agents B2.

  A plurality of file agents C2 exist and communicate with the file client C1 of the application C7. The file information DBC31 is shared by a plurality of file agents C2.

  First, the application A7 executes the file registration unit 11 of the file client A1 when outputting data. Since there are a plurality of file clients A1, a plurality of files can be output in parallel.

  Subsequently, the file agent B2 receives a file registration request addressed to the application B7 from the application A7, and creates a file in the file storage device 32.

  Subsequently, the file agent C2 receives a file registration request addressed to the application C7 from the application A7, and creates a file in the file storage device 32.

  Subsequently, when all the files are output in one transaction, the application A7 executes the commit unit 13 of the file client A1.

  Subsequently, the file agent B2 receives the commit request from the application A7, and stores the file information in the file information DBB31.

  Subsequently, the file agent C2 receives the commit request from the application A7, and stores the file information in the file information DBC31.

  Subsequently, the application A7 notifies the registered file information to the application B7 and the application C7 via the network.

  Subsequently, the application B7 executes the file acquisition unit 12 of the file client B1 in order to input a file based on the file information received from the application A7. Since there are a plurality of file clients B1, a plurality of files can be input in parallel.

  Subsequently, the file agent B2 receives a file acquisition request from the application B7, and acquires a file from the file storage device 32 or the cache storage unit 26.

  Subsequently, the application B7 updates the database DB-B8 with respect to the acquired file data, and outputs the data to the application C7.

  Subsequently, the file agent C2 receives a file registration request addressed to the application C7 from the application B7, and creates a file in the file storage device 32.

  Subsequently, when all the files are output in one transaction, the application B7 executes the commit unit 13 of the file client B1.

  Subsequently, the file agent C2 receives the commit request from the application B7, deletes the input file, and stores the file information in the file information DBC31.

  Subsequently, the application B7 notifies the registered file information to the application C7 via the network.

  Subsequently, the application C7 executes the file acquisition unit 12 of the file client C1 in order to input a file based on the file information received from the application A7 and the application B7. Since there are a plurality of file clients C1, a plurality of files can be input in parallel.

  Subsequently, the file agent C2 receives a file acquisition request from the application B7 and acquires a file from the file storage device 32 or the cache storage unit 26.

  Subsequently, the application C7 processes data from the acquired file and updates the database DB-C9.

  Subsequently, when all the files are input in one transaction, the application C7 executes the commit unit 13 of the file client C1.

  The file agent C2 receives the commit request from the application C7 and deletes the input file.

  As described above, data is exchanged between the applications.

  Regarding the operation at the time of failure, recovery is performed as in the following (1) to (3).

  (1) When the application B7 is in a transaction and the AP server B5 becomes a failure before committing after file registration.

  After the recovery, the AP server B5 executes the rollback unit 14 and requests the file agent B2 and the file agent C2 to roll back.

  The file agent B2 deletes the input transaction identifier from the file information DBB31.

  The file agent C2 deletes the file with the corresponding transaction identifier from the file storage device 32, and deletes the file information corresponding to the output transaction identifier from the temporary registration list storage unit 25 of the file agent C2.

  Thereafter, the application B7 executes the list acquisition unit 15 of the file client B1, acquires the list of file information held by the file agent B2, and resumes the transaction.

  (2) When the application server B7 is in a transaction, the file registration is performed, and the AP server B5 becomes a failure during the commit.

  The AP server B5 recovers and the application B7 is restarted, and the list is acquired for the file agent A2, the file agent B2, and the file agent C2.

  From the acquired file information, determine whether the commit that was being performed at the time of the failure was successful (in the case of output, if the transaction identifier file exists, it is determined to be successful; in the case of input, the input transaction identifier file is If it does not exist, it is considered as successful.) If it fails, the commit is requested again.

  (3) When the file server 6 becomes a failure during the commit after the file registration in the application B7 during the transaction.

  Since the file client B1 of the AP server B5 cannot obtain a commit response, the file client B1 determines that the file agent has failed and makes a commit request again after re-establishing the communication path.

  The file agent B2 performs the same commit process as usual and returns a response.

  As described above, the transaction processing system according to this embodiment has the following effects (1) to (4).

  (1) Writing can be guaranteed without causing the application to hang up due to a file server failure.

  This is because NFS is not used. In the file agent 2, when the file access control unit 22 completes writing to the file storage device 32 and file information is registered in the temporary registration list storage unit 25, it is determined that the data is stored in the file. The file storage device 32 needs to be able to guarantee the writing of the write request from the file access control unit 22 when the writing is completed.

  (2) When the processing on the input side stops due to a server abnormality, the upper limit of the length of the period until the processing on the output side is stopped can be increased.

  This is because the file information DB 31 eliminates the need for being restricted by the conventional file storage location restrictions (files of the same transaction must be stored in one directory).

  (3) It is possible to improve the server restart performance when a file stays.

  This is because the file information DB 31 can acquire a file list without disk access, and therefore, when there are a large number of files, the speed of file list acquisition can be improved.

  (4) Transaction speed performance can be improved.

  This is because one of the bottlenecks of transaction performance is file access, and therefore transaction performance can be improved by improving file access performance. First, since open, read / write, and close are performed with a single request / response, the number of communications can be reduced compared to NFS. In addition, since it can be included as a file protocol of the concept of transaction, a plurality of files can be processed without specifying a file name for each transaction, such as renaming and deleting input containers. In addition, an optimal file cache can be provided, and access to the physical disk can be reduced. The optimal file cache is to leave the oldest file in the server, not the last file written, in memory.

[Modification]
Note that the above-described embodiment is merely an example, and does not exclude various modifications and technical applications that are not explicitly described in the embodiment. That is, the present invention can be implemented by being modified into various forms without departing from the spirit of the present invention.

  For example, some or all of the above-described embodiments can be described as in the following supplementary notes, but the present invention is not limited to the following.

  (Supplementary note 1) A file client that transmits a request in a predetermined unit of operation and a file agent that transmits a result for the request each time the request is received, the file agent including a transaction corresponding to the request A communication control unit that generates a directory name using a hash value of an identifier, a file access control unit that registers a file to be registered in a file storage device when receiving a registration request as the request, and the registration request A temporary registration list storage unit that temporarily registers file information to be registered, and a file information control unit that stores the temporarily registered file information in the file information DB when a commit request is received as the request. The file access control unit, the temporary registration list storage unit, and the file Le information control unit, the transaction processing system when it receives a rollback request as the request to delete the file information corresponding to the uncompleted transaction, characterized in that.

  (Appendix 2) A method for controlling a transaction processing system comprising: a file client that transmits a request in a predetermined unit of operation; and a file agent that transmits a result for the request each time the request is received, A step of generating a directory name using a hash value of a transaction identifier corresponding to the request; and a step of registering a file to be registered in a file storage device when receiving a registration request as the request; A step of temporarily registering file information to be registered when the registration request is received; a step of storing temporarily registered file information in a file information DB when a commit request is received as the request; Incomplete when a rollback request is received Transaction processing method characterized by comprising the step of deleting the file information corresponding to the transaction, the.

  DESCRIPTION OF SYMBOLS 1 ... File client, 2 ... File agent, 4 ... External input device, 5 ... AP server, 6 ... File server, 7 ... Application, 8, 9 ... Database, 10 ... Communication control part, 11 ... File registration part, 12 ... File acquisition unit 13 ... Commit unit 14 ... Rollback unit 15 ... List acquisition unit 20 ... Communication control unit 21 ... File information control unit 22 ... File access control unit 23 ... Cache control unit 25 ... Temporary Registration list storage unit, 26 ... cache storage unit, 31 ... file information DB, 32 ... file storage device.

Claims (2)

A file client that sends a request to a given unit of operation;
A file agent that transmits a result for the request each time the request is received, and
The file agent is
A communication control unit that generates a directory name using a hash value of a transaction identifier corresponding to the request;
A file access control unit that registers a file to be registered in the file storage device when a registration request is received as the request;
A temporary registration list storage unit that temporarily registers file information to be registered when the registration request is received;
A file information control unit that stores temporarily registered file information in the file information DB when a commit request is received as the request;
The file access control unit, the temporary registration list storage unit, and the file information control unit delete file information corresponding to an incomplete transaction when receiving a rollback request as the request.
A transaction processing system characterized by that. A method for controlling a transaction processing system comprising: a file client that transmits a request to a predetermined unit of operation; and a file agent that transmits a result for the request each time the request is received,
The file agent is
Generating a directory name using a hash value of a transaction identifier corresponding to the request;
Registering a file to be registered in a file storage device when a registration request is received as the request;
Temporarily registering file information to be registered when the registration request is received;
Storing the provisionally registered file information in the file information DB when a commit request is received as the request;
Deleting a file information corresponding to an incomplete transaction when a rollback request is received as the request;
A transaction processing method comprising:

Images