JP3774075B2 - Transaction division / cooperation apparatus and recording medium - Google Patents

Description

というように、入力データとして同じ支店コードのレコードが複数あった場合に、これらを１つのトランザクションとして自動分割して１トランザクションにすることで、データベース中の同じ位置に格納されているレコードをまとめて１トランザクションで処理するこで、効率的かつ高速に顧客の残高などのデータを参照することが可能となる共に、トランザクションを所定ブロックに自動分割したことでリカバリや他の処理の迅速化を図ることが可能となる。
【００４５】
次に、図８から図１３を参照して本発明の他の実施例構成および動作を詳細に説明する。
図８は、本発明の他の概念システム図を示す。
【００４６】
図８の（ａ）、（ｂ）、（ｃ）において、アプリケーションプログラム（入出力）３１は、図示外のバッチ業務から１トランザクションで複数のデータブロックのデータベース３４へのアクセス（更新）を複数のトランザクションに自動分割して処理を行うものである。
【００４７】
入力データファイル３２は、ここでは、データベース３４へ書き込むデータなどを格納するファイルである。
入力データ管理テーブル３３は、入力データの情報を管理するものである。
【００４８】
トランザクションリカバリ処理３６は、トランザクションで異常発生時にリカバリを行うものである。
ログファイル５は、ログを保存するファイルである。
【００４９】
次に、それそれの動作を説明する。
図８の（ａ）は、正常実行時の動作を示す。
（１） トランザクション開始する（例えば初回はデータベース３４をオープンしてトランザクションを開始、２回目以降はトランザクションを開始する）。
【００５０】
（２） ＲＥＡＤ実行し、入力データファイル３２から読み出したデータについて、データベース３４を検索してＤＢ更新する。
（３） トランザクション終了する。この中でログファイルにログ採取および入力データ管理テーブル３３に情報（位置付け情報）を書き込む。
【００５１】
（４） 正常終了したときは、次のデータについて繰り返す。
図８の（ｂ）は、リカバリ時の動作を示す。
（１） トランザクションで障害発生時に、図８の（ａ）で採取したログファイル３５を参照して、トランザクションリカバリ処理３６を構成する整合性回復手段が入力データ管理テーブル３３と、データベース３４との整合性を回復させる。これにより、障害発生したトランザクション以前で処理したデータの整合性が回復されることとなる。
【００５２】
図８の（ｃ）は、リラン時の動作を示す。
（２） 図８の（ｂ）で整合性の回復を行った後、障害発生したトランザクションについて、リラン（再実行）し、再実行したトランザクションに対応するデータの部分からデータベース３４に再実行を行う。
【００５３】
以上によって、トランザクションのいずれかで障害発生時に、正常な部分は整合性を回復した後、回復できない部分（トランザクション）についてリラン（再実行）して再書き込みを行うことにより、障害発生のトランザクションのみを再実行すればよく、効率的にリカバリおよび再実行を行うことが可能となる。以下順次詳細に説明する。
【００５４】
図９は、本発明のシステム構成図を示す。これは、既述した図２のシステム構成図中の、１１，１２，１３，１４，１５，１７，１８，１９，２０，２１，２２，２３と同一であるので説明を省略する。
【００５５】
次に、図１０のフローチャートの順番に従い、図９の構成の動作を詳細に説明する。
図１０は、本発明の他の動作説明フローチャート（その１）を示す。
【００５６】
図１０において、Ｓ７１は、初回のデータ読込要求か、または、前回読込データブロックの処理完了か判別する。ＹＥＳの場合には、Ｓ７２に進む。ＮＯの場合には、Ｓ８１でデータブロックのでブロッキングを行い、レコード返却し、終了などする。
【００５７】
Ｓ７２は、初回のデータ読込み要求か判別する。ＹＥＳの場合には、Ｓ７３に進む。ＮＯの場合には、初回のデータ読込みでもないと判明したので、Ｓ８４でデータの読込みを行い、Ｓ８１でデータブロックのでブロッキングを行い、レコードを返却して最初に戻るなどする。
【００５８】
Ｓ７３は、入力データ管理テーブルの当該ジョブのエントリを検索する。
Ｓ７４は、エントリありか判別する。ＹＥＳの場合には、リカバリと判明したので、Ｓ７５で完了済トランザクション情報の読込みを行い、Ｓ７６に進む。一方、ＮＯの場合には、初回と判明したのでＳ８４でデータの読込みを行い、Ｓ８１でデータブロックのでブロッキングを行う。
【００５９】
Ｓ７６は、トランザクション情報ありか判別する。 ＹＥＳの場合には、Ｓ７７に進む。ＮＯの場合には、Ｓ８４でデータの読込みを行い、Ｓ８１でデータブロックのでブロッキングを行う。
【００６０】
Ｓ７７は、トランザクション完了済のデータレコードはブロック内最終レコード以外か判別する。ＹＥＳの場合には、Ｓ７８で最後のトランザクション完了済のデータブロックに位置づけ、Ｓ７９でデータの読込みを行い、Ｓ８０で最後のトランザクション完了済のデータレコードの次のレコードに位置づけ、Ｓ８１でデータブロックのでブロッキングを行う。一方、Ｓ７７のＮＯの場合には、最後のトランザクション完了済のデータブロックの次のブロックに位置づけ、Ｓ８３でデータの読込みを行い、Ｓ８１でデータブロックのでブロッキングを行う。
【００６１】
以上によって、既述した図８の（ｂ）、（ｃ）に示すように、Ｓ７８、Ｓ７９、Ｓ８０およびＳ８２、Ｓ８３の手順を区別し、異常発生個所のトランザクションに依存してリカバリ／リトライを効率的に行うことが可能となる。
【００６２】
図１１は、本発明の動作説明フローチャート（その２）を示す。
図１１において、Ｓ９１は、入力データ管理手段がトランザクション完了前処理を行う。これにより、入力データ管理手段がＳ１０１で入力データ管理テーブルの当該ジョブのエントリを検索し、Ｓ１０２でエントリありか判別し、ＹＥＳのときに、Ｓ１０３で当該ジョブのエントリの切り出し／初期化を行い、Ｓ１０４で仕掛かり中のトランザクション情報を設定し、Ｓ９１に戻る。一方、Ｓ１０２のＮＯの場合には、Ｓ１０４で仕掛かり中のトランザクション情報を設定し、Ｓ９１に戻る。
【００６３】
Ｓ９２は、ログファイルへのトランザクション履歴情報を出力する。
Ｓ９３は、データベース制御部がデータベース実更新を行う。
Ｓ９４は、入力データ管理手段がトランザクション完了後処理を行う。これにより、Ｓ１１１で入力データ管理テーブルの当該ジョブのエントリを検索し、Ｓ１１２でエントリありかつ仕掛かり中のトランザクションありか判別し、ＹＥＳの場合にＳ１１３で仕掛かり中のトランザクション情報の内容を完了済トランザクション情報に複写し、Ｓ９４に戻る。一方、Ｓ１１２のＮＯの場合には、エラーとして終了する。
【００６４】
以上によって、ログファイルにトランザクション履歴情報を出力し、トランザクション終了要求を行うことが可能となる。
図１２は、本発明の動作説明フローチャート（その３）を示す。
【００６５】
図１２において、Ｓ１２１は、トランザクション制御部がログファイルからのトランザクション履歴情報を読み込む。
Ｓ１２２は、データベース制御部がデータベースのリカバリを行う。
【００６６】
Ｓ１２３は、未処理の完了済トランザクションありか判別する。ＹＥＳの場合には、Ｓ１２４で入力データ管理手段がトランザクションリカバリ処理を行う。これは、図示の矢印しのように、入力データ管理手段がＳ１３１で入力データ管理テーブルの当該トランザクションのエントリを検索し、Ｓ１３２でエントリあり、かつ仕掛かり中のトランザクションありか判別し、ＹＥＳの場合にＳ１３４で仕掛かり中トランザクション情報の内容を完了済トランザクション情報に複写し、Ｓ１２４に戻る。一方、Ｓ１３２のＮＯの場合には、Ｓ１２４にそのまま戻る。
【００６７】
以上によって、ログファイルからトランザクション履歴情報を読み込み、データベースのリカバリを行うと共に、入力データ管理テーブルにエントリがありかつ仕掛かり中トランザクションの場合に複写して復元（リカバリ）することが可能となる。
【００６８】
図１３は、本発明のテーブル例を示す。これは、既述した図６のテーブルと同じであるので、説明を省略する。
【００６９】
【発明の効果】
以上説明したように、本発明によれば、バッチジョブのトランザクションを入力データのブロックごとなどに自動分割し、業務アプリケーションプログラムを変更することなくオンライン業務と平行しても迅速なレスポンスを実現、タイムアウト発生を無くすと共に、リカバリ時にバッジ業務で設定したトランザクションを自動分割したときに効率的にリカバリ処理を実行することが可能となる。
【図面の簡単な説明】
【図１】本発明の概念システム図である。
【図２】本発明のシステム構成図である。
【図３】本発明の動作説明フローチャート（その１）である。
【図４】本発明の動作説明フローチャート（その２）である。
【図５】本発明の動作説明フローチャート（その３）である。
【図６】本発明のテーブル例である。
【図７】本発明のトランザクションの他の例である。
【図８】本発明の他の概念システム図である。
【図９】本発明のシステム構成図である。
【図１０】本発明の他の動作説明フローチャート（その１）である。
【図１１】本発明の他の動作説明フローチャート（その２）である。
【図１２】本発明の他の動作説明フローチャート（その３）である。
【図１３】本発明の他のテーブル例である。
【符号の説明】
１、１２、３１：アプリケーション（入出力）
２、２１、３２：入力データファイル
３、２３、３４：データベース
１６：トランザクション分割手段
１９、３５：ログファイル
２２、３３：入力データ管理ファイル[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a transaction dividing / cooperating apparatus and a recording medium.
[0002]
[Prior art]
Conventionally, since a batch job generally processes one job step of a batch job as one transaction, the number of records to be processed in one transaction depends on the data amount of input data.
[0003]
[Problems to be solved by the invention]
For this reason, the database exclusive time becomes long, and there is a problem that the response time of online work (the number of records processed in one transaction is several records) deteriorates and a timeout occurs.
[0004]
In addition, there is a problem that system resources (such as memory) temporarily used for each transaction by the transaction control program increase in proportion to the number of records processed in one transaction, and the system resources are exhausted.
[0005]
In addition, if an application program terminates abnormally or the system goes down during the execution of a batch job, the database is recovered to the state before the execution of the batch job, so all input data is processed again by re-executing the batch job. There is also a problem that it takes a long time to recover the business.
[0006]
In addition, it is conceivable to divide transactions with application programs, but in order to divide transactions with application programs for various business operations, it is necessary to change the program for each business program application and due to incomplete specifications. There is a problem that it is difficult to realize transaction division in an actual business application.
[0007]
In addition, it is desired to efficiently execute recovery when a transaction set in a batch job is automatically divided.
In order to solve these problems, the present invention automatically divides batch job transactions into blocks of input data, etc., and realizes quick response even in parallel with online business without changing business application program, timeout The purpose is to eliminate the occurrence and to efficiently execute the recovery process when the transaction set in the badge operation at the time of recovery is automatically divided.
[0008]
[Means for Solving the Problems]
Means for solving the problem will be described with reference to FIGS.
In FIG. 1 and FIG. 8, the application (input / output) 1 opens or accesses the database 3, divides a transaction for each access of a predetermined block, closes the database 3, etc. It is.
[0009]
The input data file 2 stores input data.
The database 3 is accessed for each predetermined block, and manages a large amount of data.
[0010]
Next, the operation will be described.
As shown in FIG. 1, when an application program (input / output) 1 accesses a database 3, a transaction is automatically divided for each access of a predetermined block of input data, and is executed for each transaction and for each predetermined block. Log information is saved in a log file.
[0011]
Further, when any failure occurs during the execution of a transaction, a predetermined block of the failed transaction is re-executed by referring to the log file to recover.
[0012]
Further, a plurality of records having the same code are set for each predetermined block of input data.
Further, as shown in FIG. 8, when the application program (input / output) 31 accesses the database 34, it is automatically divided into transactions for each access for each predetermined block of input data, and information for each predetermined block is stored in a file. When a failure occurs during a transaction, the file is referenced to restore the consistency of the data source and destination of the failed data, and then re-execute after the specified block of the failed transaction to recover. I have to.
[0013]
Therefore, batch job transactions are automatically divided into blocks of input data, etc., enabling quick response even when parallel to online work without changing business application programs, eliminating timeouts, and enabling badge work during recovery Recovery processing can be efficiently executed when a set transaction is automatically divided.
[0014]
【Example】
Next, embodiments and operations of the present invention will be described sequentially in detail with reference to FIGS.
[0015]
FIG. 1 shows a conceptual system diagram of the present invention.
FIG. 1A shows a conceptual system diagram of the present invention.
In FIG. 1A, the application (input / output) 1 opens or accesses the database 3, divides a transaction for each access of a predetermined block, closes the database 3, and the like. It is a thing which performs input / output processing.
[0016]
The input data file 2 stores input data.
The database 3 accesses a predetermined block unit, and manages a large amount of data.
[0017]
FIG. 1B shows an example of a transaction sequence. This shows an example of an automatic division sequence of one transaction in the conceptual system diagram of FIG. 1A, and one transaction is automatically divided for each predetermined block of input data as shown in the following.
[0018]
First time: (1) → (2): The start of the first transaction is when the database 3 is opened, and the end of the transaction is after access to the database of a predetermined block of input data, for example, after reading.
[0019]
2nd to nth times: (3) → (2): The transaction starts at the first time or immediately after the previous transaction ends, and the transaction ends by accessing the database 3 for a predetermined block of input data and processing the transaction. Is when you finished.
[0020]
Last round: {circle over (3)} {circle over (4)}: The start of the transaction is at the last n times of the second to nth times, and the end of the transaction is when the database 3 is closed.
[0021]
As described above, by automatically dividing a transaction for each predetermined block of input data, log information etc. is collected for each transaction, and when a failure occurs in a transaction, only the relevant transaction etc. is re-read by looking at the log information. It only has to be executed, and recovery can be performed very quickly. Details will be sequentially described below.
[0022]
FIG. 2 shows a system configuration diagram of the present invention.
In FIG. 2, the control device 11 performs overall control of the whole, and includes 12 to 20.
[0023]
The application program (input / output) 12 performs data reading, record search, record update, and the like.
The database control means 13 is for accessing the database 23.
[0024]
The data reading unit 14 reads data from the input data file 21.
The data input control means 15 reads data from the input data file 21.
[0025]
The transaction dividing means 16 automatically divides a transaction into predetermined blocks of input data.
The transaction control means 17 stores log information in the log file 19 for each transaction, or stores input management information for each transaction in the input data management table 22.
[0026]
The input data management means 18 stores input data management information for each transaction in the input data management table 22 or the like.
The log file 19 is a file for storing log information for each transaction.
[0027]
The input data management table 22 stores input data management information for each transaction.
The transaction recovery control means 20 refers to the log file 19 and takes out log information of the failed transaction, and re-executes from the failed transaction based on the log information.
[0028]
The database 23 manages various data so as to be easily searched.
Next, the operation of the configuration of FIG. 2 will be described in detail according to the order of the flowchart of FIG.
[0029]
FIG. 3 is a flowchart for explaining the operation of the present invention (part 1).
In FIG. 3, S1 determines whether it is the first data read request or the previous read data block processing is completed. If YES, the process proceeds to S2. If NO, the data block is blocked at S10, the record is returned, and the process is terminated.
[0030]
In S2, it is determined whether it is the first data reading request. If YES, the process proceeds to S3. In the case of NO, since it was found that the data was not read for the first time, the data is read in S8, the transaction is divided in S9 by S11 to S14 to be described later, and the data block is blocked in S10 after the automatic division of the transaction. And return records to the beginning.
[0031]
In step S3, the entry of the job in the input data management table is searched.
In S4, it is determined whether there is an entry. In the case of YES, since it is found that the transaction is recovery, the completed transaction information is read in S5, and the process proceeds to S6. On the other hand, in the case of NO, since the first time is found, S8 and subsequent steps are performed.
[0032]
In S6, it is determined whether there is transaction information. In the case of YES, it is positioned in the next data block after the last transaction completed data block in S7, and the process proceeds to S8. On the other hand, if NO, the process proceeds to S8.
[0033]
In S8, data is read.
In step S9, transaction division is performed. As described above, automatic transaction division is performed in S11 to S14 described later.
[0034]
In S10, the data block is blocked, the record is returned, and the process proceeds to the next process.
In S11 and S12, the transaction control means ends the transaction.
[0035]
In S13 and S14, the transaction control means starts a transaction.
As described above, as shown in FIG. 1B, the three-stage transaction can be automatically divided under the configuration shown in FIG.
[0036]
FIG. 4 shows a flowchart (part 2) for explaining the operation of the present invention.
In FIG. 4, in S21, the input data management means performs transaction completion notification pre-processing. As a result, the input data management means searches for the entry of the job in the input data management table in S31, and when there is an entry (YES), the entry of the job is cut out / initialized in S33, and the work is started in S34. The middle transaction information is set and the process returns to S21. On the other hand, in the case of NO in S32, since it is determined that there is no entry, in-transaction transaction information is set in S34 and the process returns to S21.
[0037]
In step S22, transaction history information to the log file is output.
In S23, the database control unit performs actual database update.
In S24, the input data management unit performs post-transaction processing. As a result, the input data management means retrieves the entry of the job in the input data management table in S41, determines in S42 whether there is an entry and a transaction in progress, and if YES, the transaction information in progress in S43 is determined. The contents are copied to the completed transaction information, and the process returns to S24. On the other hand, if NO in S42, the process ends as an error.
[0038]
As described above, during transaction pre-processing and post-processing, it is possible to copy transaction history information, database actual update, and the contents of in-process transaction information to completed information.
[0039]
FIG. 5 shows a flowchart (part 3) for explaining the operation of the present invention.
In FIG. 5, in S51, the transaction control unit reads transaction history information from the log file.
[0040]
In S52, the database control unit recovers the database.
S53 determines whether there is an unprocessed completed transaction. If YES, the input data management means performs transaction recovery processing in S54. As indicated by the arrow in the figure, the input data management means copies the contents of the transaction information in the input data management table to the completed transaction information in S61, and returns to S54. On the other hand, in the case of NO in S62, since it has been found that there is an entry and there is no transaction in progress, the processing is terminated as it is.
[0041]
As described above, the transaction history information is read from the log file and the database is recovered, and when the input data management table has an entry and the transaction is in progress, it can be copied and restored (recovered).
[0042]
FIG. 6 shows an example table of the present invention. Here, the following information shown in the figure is set.
-Pointer for each entry:
・ Job information (* 1)
-Transaction identification number of the transaction in progress (* 2)
-Data block positioning information corresponding to the transaction in progress (* 3)
-Transaction identification number of the completed transaction (* 2)
-Positioning of data blocks corresponding to completed transactions (* 3)
here,
* 1 is job information, which is information for identifying a batch job.
[0043]
* 2 is a transaction identification number, which is information for identifying a transaction and is unique in the system.
* 3 is data block positioning information, which is information for identifying the data block in the file. In the case of DASD, the volume serial number, the file name, the relative track address, etc. In the case of MT Is the volume and street number. File order number, block number, etc.
[0044]
FIG. 7 shows another example of the transaction of the present invention. Here, as shown, as input data,

Thus, when there are multiple records of the same branch code as input data, these records are automatically divided into one transaction, and the records stored at the same position in the database are collected together. By processing in one transaction, data such as customer balance can be referred to efficiently and at high speed, and recovery and other processing can be speeded up by automatically dividing the transaction into predetermined blocks. Is possible.
[0045]
Next, the configuration and operation of another embodiment of the present invention will be described in detail with reference to FIGS.
FIG. 8 shows another conceptual system diagram of the present invention.
[0046]
8A, 8B, and 8C, the application program (input / output) 31 performs access (update) to a plurality of data block databases 34 in a single transaction from a batch job (not shown). Processing is automatically divided into transactions.
[0047]
Here, the input data file 32 is a file for storing data to be written to the database 34.
The input data management table 33 manages input data information.
[0048]
The transaction recovery process 36 performs recovery when an abnormality occurs in the transaction.
The log file 5 is a file for storing a log.
[0049]
Next, each operation will be described.
FIG. 8A shows the operation at normal execution.
(1) Start a transaction (for example, the database 34 is opened for the first time to start a transaction, and the transaction is started for the second and subsequent times).
[0050]
(2) Execute READ and search the database 34 for data read from the input data file 32 to update the DB.
(3) End the transaction. In this, information (positioning information) is written in the log collection and input data management table 33 in the log file.
[0051]
(4) When the process ends normally, repeat for the next data.
FIG. 8B shows the operation at the time of recovery.
(1) When a failure occurs in a transaction, the consistency recovery means constituting the transaction recovery process 36 refers to the log file 35 collected in FIG. 8A to make the input data management table 33 and the database 34 consistent. Restores sex. As a result, the consistency of data processed before the failed transaction is restored.
[0052]
FIG. 8C shows the operation during rerun.
(2) After the consistency is restored in FIG. 8B, the failed transaction is rerun (re-executed), and the database 34 is re-executed from the data portion corresponding to the re-executed transaction. .
[0053]
As described above, when a failure occurs in one of the transactions, after restoring the integrity of the normal part, rerun (re-execute) the unrecoverable part (transaction) and rewrite it, so that only the failed transaction is restored. Re-execution is sufficient, and recovery and re-execution can be performed efficiently. Details will be sequentially described below.
[0054]
FIG. 9 shows a system configuration diagram of the present invention. This is the same as 11, 12, 13, 14, 15, 17, 18, 19, 20, 21, 21, 23 in the system configuration diagram of FIG.
[0055]
Next, the operation of the configuration of FIG. 9 will be described in detail according to the order of the flowchart of FIG.
FIG. 10 is a flowchart for explaining another operation of the present invention (part 1).
[0056]
In FIG. 10, S71 determines whether it is the first data read request or the process of the previously read data block is completed. If YES, the process proceeds to S72. If NO, the data block is blocked in S81, the record is returned, and the process is terminated.
[0057]
In S72, it is determined whether it is the first data reading request. If YES, the process proceeds to S73. In the case of NO, since it has been found that it is not the first data read, the data is read in S84, the data block is blocked in S81, the record is returned, and the process returns to the beginning.
[0058]
In step S73, the entry of the job in the input data management table is searched.
In S74, it is determined whether there is an entry. In the case of YES, since it is found that the transaction has been recovered, the completed transaction information is read in S75, and the process proceeds to S76. On the other hand, in the case of NO, since it is determined to be the first time, the data is read in S84, and the data block is blocked in S81.
[0059]
In S76, it is determined whether there is transaction information. If YES, the process proceeds to S77. If NO, the data is read in S84, and the data block is blocked in S81.
[0060]
In S77, it is determined whether the data record for which the transaction has been completed is other than the last record in the block. If YES, the data block is positioned at the last transaction completed data block at S78, the data is read at S79, positioned at the record next to the data transaction completed at S80, and the data block is blocked at S81. I do. On the other hand, in the case of NO in S77, it is positioned as the block next to the last transaction completed data block, the data is read in S83, and the data block is blocked in S81.
[0061]
As described above, as shown in FIGS. 8B and 8C, the procedures of S78, S79, S80, S82, and S83 are distinguished, and recovery / retry is efficiently performed depending on the transaction where the abnormality occurred. Can be performed automatically.
[0062]
FIG. 11 is a flowchart (part 2) for explaining the operation of the present invention.
In FIG. 11, in S91, the input data management means performs pre-transaction completion processing. Thereby, the input data management means searches for the entry of the job in the input data management table in S101, determines whether or not there is an entry in S102, and if YES, cuts out / initializes the entry of the job in S103, In S104, in-process transaction information is set, and the process returns to S91. On the other hand, in the case of NO in S102, the transaction information in progress is set in S104, and the process returns to S91.
[0063]
In step S92, the transaction history information to the log file is output.
In S93, the database control unit performs actual database update.
In S94, the input data management means performs post-transaction completion processing. As a result, the entry of the job in the input data management table is searched in S111, it is determined whether there is an entry and a transaction in progress in S112. If YES, the contents of the transaction information in progress are completed in S113. Copy to transaction information and return to S94. On the other hand, if NO in S112, the process ends as an error.
[0064]
As described above, it is possible to output transaction history information to a log file and make a transaction end request.
FIG. 12 shows a flowchart (part 3) for explaining the operation of the present invention.
[0065]
In FIG. 12, in S121, the transaction control unit reads transaction history information from the log file.
In S122, the database control unit recovers the database.
[0066]
In step S123, it is determined whether there is an unprocessed completed transaction. In the case of YES, the input data management means performs transaction recovery processing in S124. As indicated by the arrow in the figure, the input data management means searches for the entry of the transaction in the input data management table in S131, determines whether there is an entry and a transaction in progress in S132, and if YES In S134, the contents of the in-process transaction information are copied to the completed transaction information, and the process returns to S124. On the other hand, in the case of NO in S132, the process returns to S124 as it is.
[0067]
As described above, the transaction history information is read from the log file and the database is recovered, and when the input data management table has an entry and the transaction is in progress, it can be copied and restored (recovered).
[0068]
FIG. 13 shows an example table of the present invention. Since this is the same as the table of FIG. 6 already described, description thereof is omitted.
[0069]
【The invention's effect】
As described above, according to the present invention, a batch job transaction is automatically divided into blocks of input data, etc., and a quick response is realized even in parallel with online business without changing the business application program. In addition to eliminating the occurrence, it is possible to efficiently execute the recovery process when the transaction set in the badge job at the time of recovery is automatically divided.
[Brief description of the drawings]
FIG. 1 is a conceptual system diagram of the present invention.
FIG. 2 is a system configuration diagram of the present invention.
FIG. 3 is a flowchart (part 1) for explaining the operation of the present invention.
FIG. 4 is a flowchart (part 2) illustrating the operation of the present invention.
FIG. 5 is a flowchart (part 3) illustrating the operation of the present invention.
FIG. 6 is a table example of the present invention.
FIG. 7 is another example of a transaction of the present invention.
FIG. 8 is another conceptual system diagram of the present invention.
FIG. 9 is a system configuration diagram of the present invention.
FIG. 10 is a flowchart (part 1) illustrating another operation of the present invention.
FIG. 11 is a flowchart (part 2) illustrating another operation of the present invention.
FIG. 12 is a flowchart (No. 3) for explaining another operation of the invention.
FIG. 13 is another table example of the present invention.
[Explanation of symbols]
1, 12, 31: Application (input / output)
2, 21, 32: input data files 3, 23, 34: database 16: transaction dividing means 19, 35: log files 22, 33: input data management file

Claims (5)

An input data management table for storing in-process and completed transaction information in association with batch job identification information;
Transaction splitting means for requesting the transaction control unit to end the immediately preceding transaction and start a new transaction,
A data reading unit that receives a request for data reading from the application program, inputs the input data in a predetermined unit from the input data file via the data input control unit, and calls the transaction dividing unit;
Transaction completion processing means that receives control from the transaction control unit activated based on the transaction end request and stores the information of the transaction that is the end request target as in-progress transaction information in the input data management table, and transaction control after database update An input data management means comprising a post-transaction completion processing means for copying the in-process transaction information set in the input data management table to the completed transaction information and storing it in the input data management table. A transaction dividing / cooperating apparatus characterized by comprising:   2. The apparatus according to claim 1, further comprising means for re-executing a recovery in a predetermined unit of a failed transaction by referring to the input data management table when a failure occurs during the execution of the transaction. The transaction splitting / linking device described.   2. The transaction division / cooperation apparatus according to claim 1, wherein the data reading means inputs input data in units of either data blocks or having the same code. A transaction splitting step for requesting the transaction control unit to end the immediately preceding transaction and start a new transaction;
A data reading step for receiving a request for reading data from an application program and inputting the input data in a predetermined unit from the input data file via the data input control unit and calling the transaction dividing step;
Control is passed from the transaction control unit activated based on the transaction end request, and information on the transaction requested for end is stored as in-process transaction information, and in-process and completed transaction information is associated with batch job identification information and stored. The transaction completion preprocessing step stored in the input data management table to be transferred, and the control from the transaction controller after the database update is transferred, and the in-process transaction information set in the input data management table is copied to the completed transaction information. A computer-readable recording medium recording a transaction division / cooperation program for executing an input data management step for executing a transaction completion post-processing step stored in a data management table. A transaction splitting step for requesting the transaction control unit to end the immediately preceding transaction and start a new transaction;
A data reading step for receiving a request for reading data from an application program and inputting the input data in a predetermined unit from the input data file via the data input control unit and calling the transaction dividing step;
Control is passed from the transaction control unit activated based on the transaction end request, and information on the transaction requested for end is stored as in-process transaction information, and in-process and completed transaction information is associated with batch job identification information and stored. The transaction completion preprocessing step stored in the input data management table to be transferred, and the control from the transaction controller after the database update is transferred, and the in-process transaction information set in the input data management table is copied to the completed transaction information. A computer-readable recording medium recording a transaction division / cooperation program for executing an input data management step for executing a transaction completion post-processing step stored in a data management table.

Images