JP3732113B2 - Transaction control system, method and program - Google Patents
Transaction control system, method and program Download PDFInfo
- Publication number
- JP3732113B2 JP3732113B2 JP2001143203A JP2001143203A JP3732113B2 JP 3732113 B2 JP3732113 B2 JP 3732113B2 JP 2001143203 A JP2001143203 A JP 2001143203A JP 2001143203 A JP2001143203 A JP 2001143203A JP 3732113 B2 JP3732113 B2 JP 3732113B2
- Authority
- JP
- Japan
- Prior art keywords
- transaction
- derived
- derivative
- derivation
- management
- Prior art date
- Legal status (The legal status 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 status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、トランザクション制御システム及びその方法に関する。
【０００２】
【従来の技術】
従来より、大規模なデータベースに対して正確で一貫性があり障害に対して確実な復旧を可能とする処理を実現する手法として、トランザクション処理が利用されている。トランザクションは、データベース（ＤＢ）に対する処理の単位として用いられる。トランザクションは、ＤＢに一又は複数の更新を行う。このとき、トランザクションは、その性質によって、全体として成功するか又は全体として失敗するかのいずれかであることが保証される。ＤＢへの全ての更新に成功した場合に、トランザクションは同期点(syncpoint)に達する。すなわち、トランザクションはコミット(commit)する。一般的なトランザクション管理システムでは、同期点に達したトランザクションによる更新はログに記録され、このＤＢへの更新は障害に対して耐久性（Durability）を有する。
【０００３】
一方、トランザクションに含まれる処理のうち一つでも成立しなかった場合には、そのトランザクションはアボート(abort)される。トランザクションがアボートされると、そのトランザクションが行った全ての更新は取り消される。すなわち、トランザクションがアボートされると、トランザクション管理システムは、その時までに実行された全ての更新をロールバックする。このため、トランザクションは、一又は複数のプログラムを実行し、複数の更新を行っていても、全ての更新を正常に実行しコミットするか、又は、ロールバックによりなにも処理しないかのいずれかである。トランザクションは、アプリケーションにとって処理の最小単位となることから、これをトランザクションの原子性（アトミック性，Atomicity）という。
【０００４】
トランザクションは原子性を有するから、プログラマは、ＤＢの更新に際して一貫性・整合性（Consistency）を保つことができる。適用業務プログラム（アプリケーション，ＡＰＰＬ）のプログラマは、他のトランザクションによって参照されるべきではない中間的なデータの算出処理と、この中間的なデータを正常なデータへと変換又は関連させる処理とを１つのトランザクションとして包み込むことで、ＤＢの整合性、データの一貫性を保つことができる。正常なデータへ変換されたことを条件としてコミットするため、中間的なデータの状態でＤＢに格納され、他のトランザクションによってこの中間的なデータが参照されることはない。一方、正常なデータに変換されない場合には、トランザクションがアボートされるため、中間的なデータの算出及び更新もロールバックにより取り消される。
【０００５】
例えば、口座振替（資金移動）は、ある口座Ａからの数値の減算（出金）と、他の口座Ｂへの数値の加算（入金）とからなる処理である。中間的なデータは、例えばある口座Ａからの数値の減算である。この数値の減算処理と加算処理とを１つのトランザクションとして包み込むことで、口座振替に成功するか、または失敗するかのいずれかであることが保証される。この場合、数値の減算のみ又は加算のみが行われることはない。すなわち、出金と入金とを１つのトランザクションとして処理すると、出金だけが行われ、入金なされないという事態は生じない。
【０００６】
また、トランザクション間での前後関係を明確に保ち、トランザクション処理中のデータを他のトランザクションが参照できないようにすることで、複数のトランザクションを並行して処理することができる。このように、並列処理や分散処理を行うためには、トランザクション間で扱うデータを相互に隔離（Isolation）しなければならない。このデータの隔離（分離）にはロックが有効である。トランザクションが更新の可能性を持ってデータにアクセスした場合には、そのトランザクションは、そのデータ項目をロックし、必要な更新を行った後に、そのロックを解除する。トランザクションは、ロックされているデータにアクセスしようとすると、そのロックが他のトランザクションによって解除されるまで待機する。これにより、トランザクションの直列性を確保し、トランザクションに隔離性を与え、トランザクションの並列処理・分散処理が可能となる。
【０００７】
ロックを用いることで、トランザクションの直列性を維持しながら並列処理を行うことができるが、ロックの粒度（競合の単位）が大きい場合には、ロックの解除を待機する頻度が増大し、そして待機時間が長くなる傾向となる。また、ロックを使用する例では、各トランザクションのＤＢの読み込み順序によっては、デッドロックが発生する。例えば、ＤＢｘとＤＢｙがあるとき、トランザクションＴ１がＤＢｘを読み、続いて、ＤＢｙを読み出そうとするが、このＤＢｙはトランザクションＴ２によってロックされているとする。この場合、トランザクションＴ１は、ＤＢｘをロックしたまま、ＤＢｙのロックが解除されるまで待機する。トランザクションＴ２がＤＢｙを読み出した後、ＤＢｘを読み出そうとしていると、デッドロックが生じる。このように、トランザクションＴ１がＴ２の処理完了を待機し、トランザクションＴ２がＴ１の処理完了を待機する場合に、デッドロックが生じる。デッドロックは、すべてのトランザクションでＤＢの読み込み順序を同一とすることなどで回避することができる。
【０００８】
さて、トランザクションは原子性、一貫性、隔離性、耐久性のＡＣＩＤ特性を有する。この特性によるトランザクション処理を用いると、厳密で強固なシステムを構築することができる。従って、トランザクション処理システムは、金融機関での勘定系システムや、航空機等の運行や発券等の管理システムや、各種産業の製造工程の管理システムや、通信の制御システムなど、幅広い分野で利用されている。このようなシステムは、オンライン処理とバッチ処理とを実行する。例えば、従来の勘定系システムでは、日中はＡＴＭ等の端末や行内の営業店端末からの業務処理要求をオンライントランザクションとして処理し、オンラインを停止した夜間から早朝にかけて口座振替などをバッチで処理していた。
しかしながら、今日では、バッチ処理を最大限少なくし、２４時間連続運用を行うことが求められている。
【０００９】
ＡＣＩＤ特性を有するトランザクションで実行できる業務は、比較的単純な処理に限られていた。これは、１つのトランザクションで複雑な処理の実行を図ると、ロックが多数生じ、オンライン処理の応答性を悪化させてしまうことによる。また、１つのトランザクションでは処理が不可能なデータ量などがある。従来のトランザクション処理では、一般的に、オンラインでの業務処理要求を受信して即座に実行し、直ちにコミットするようにプログラムされている。
【００１０】
トランザクション間の直列性を管理するためのロッキングを行わなければ、応答性は向上するが、一方、ＤＢの一貫性を厳格に管理することができなくなる。優れた設計には英知に従った妥協が存在するが、このオンラインの応答性の確保と、より複雑な処理の実現との両立に関しては、近年、種々模索されている。この対立は、トランザクションの並列処理と、厳格な原子性とをどのように調和させるのかという点と関連する。並列処理を有効に機能させることができれば、オンライントランザクションの応答性は良好に確保される。
【００１１】
この課題に対するいくつかの手法は、例えば、“トランザクション処理システム入門”フィリップ・Ａ・バーンスタイン，エリック・ニューカマー著，日経ＢＰ社刊（Principles of Transaction Processing, Philip Bernstein, Eric Newcomer）や、“ＣＯＲＢＡ，Ｅｎｃｉｎａによるエンタープライズ・トランザクション”イアン・ゴートン著，ピアソン・エデュケーション刊（Enterprise Transaction Processing Systems: Putting the CORBA OTS, Encina++ and OrbixOTM to Work, Ian Gorton）に記載されている。
【００１２】
ＡＣＩＤ特性による単純なトランザクション管理を越える手法として、セーブポイント（save point）がある。これは、トランザクションの実行途中ですべてのリソースの状態を保存するものである。これにより、障害が発生した場合に、トランザクションの途中からの再開が可能となる。永続セーブポイントでは、トランザクションの原子性を抜きにして耐久性を与える。これにより、処理に長時間を要するトランザクションについて、全体をアボートするのではなく、途中からの再開を可能とする。セーブポイントを用いた手法は、例えば、特開２０００−１０８１０号公報に開示されている。一般的に、セーブポイントを利用しても、そのセーブポイント時でトランザクションが取り扱っているデータは他のトランザクションから隔離されるため、ロックによる競合を減らすことはできない。
【００１３】
複数のトランザクションを関連させる手法として、入れ子トランザクション（例えば、Transarc社のEncina TPモニタ）や、連鎖トランザクション（例えば、IBM社のMQシリーズ）がある。入れ子トランザクションは、トランザクションに親子関係を与えることで、トランザクション実行中に他のトランザクションを呼び出すことを可能とする。最初に起動されるトランザクションは親トランザクションとなる。この親トランザクションが呼び出したトランザクションは、副トランザクションとなる。副トランザクションは、親トランザクションに対してＡＣＩＤ特性を有するが、他のトランザクションに対しては耐久性を有さない。副トランザクションが最終的にコミットするのは、親トランザクションがコミットした場合である。副トランザクションは、同じ親を持つ他の副トランザクションに対して原子的であり、また、他のトランザクションや同じ親を持つ副トランザクションから隔離される。
【００１４】
この入れ子トランザクションモデルを用いると、振替処理という親トランザクションが、出金処理という副トランザクションと、入金処理という副トランザクションとを起動することができる。出金処理という副トランザクションがコミットすると、その結果は入金処理から参照することができる。一方、出金処理である副トランザクションのコミットによって、そのロックの管理者は親トランザクションに移る。このため、親トランザクションがコミットするまでは、その副トランザクション以外の他のトランザクションは出金処理の結果を参照することができない。従って、入金処理が何らかの理由でアボートされた場合には、親トランザクションがアボートされ、出金処理もロールバックすることができる。この入れ子トランザクションモデルは、オブジェクト指向プログラミングとの相性が良いとされている。
【００１５】
入れ子トランザクションモデルを用いると、複雑なデータ構造や処理をクラス階層で定義し、オブジェクトのメッセージと振る舞いを定義することでシステムの開発をすることができるが、副トランザクションは実際には親トランザクションがコミットするまで耐久性が与えられないため、ロックの増大が生じる可能性がある。すなわち、入れ子トランザクションモデルでは、副トランザクションを含んだ大きなトランザクションを実行しており、その大域のトランザクションは他のトランザクションに対してＡＣＩＤ特性を有する。従って、入れ子トランザクションは、プログラムの再利用性を高める点で役に立つが、親トランザクションを単位としたロックの競合を減少させることはない。
【００１６】
「連鎖(chain)」という用語は、種々の文脈で用いられている。特開平１０−６９４１８号公報では、連鎖トランザクションについて段落００６０以下に記述されている。これによると、連鎖トランザクションモデルでは、メンバトランザクションＴ３が別のメンバトランザクションＴ４を起動する。メンバトランザクションＴ４の起動処理は、起動側のメンバトランザクションＴ３の原子性に包まれる。従って、起動側のメンバトランザクションＴ３がコミットする場合のみ別のメンバトランザクションＴ４が起動される。起動されたメンバトランザクションＴ４のアボートは、トランザクションＴ３に波及しない。
【００１７】
連鎖トランザクション方式による再起動の扱いは、最近にコミットされたメンバトランザクションのコミットの状態を再び確立することによって実行される。この連鎖トランザクションモデルでは、トランザクションＴ３のコミットを早めることができる。すなわち、トランザクションＴ３は、トランザクションＴ４のコミットを待機せずにコミットすることができる。一方、連鎖トランザクションモデルでは、大域のトランザクションはＡＣＩＤ特性を有さない。従って、連鎖トランザクションモデルでは原子性は厳密ではなくなる。
【００１８】
オンライン応答性の確保を始めとする処理速度の向上を図る手法として、高速パス（Fast Path, ＦＰ）方式がある。例えば、特開平６−１９５２５０号公報には、ＩＢＭ社のＩＭＳ上に高速パスシステムを実装したシステムにて、障害時の回復のためにアクティブなデータベースの複製をバックアップシステムに連続的に維持するための手法が開示されている。ＦＰは、特に金融機関でのオンラインシステムにて応答性を向上するために用いられており、処理速度を向上させる目的で、リソースに関して種々の制限を行っている。例えば、ＦＰでは、ＩＭＳデータベースで一般的に使用されている一時的な記憶領域であるルックアサイド・データベース・バッファを使用しておらず、そして、１トランザクションで使用できるデータベースバッファ数も制限されている。さらに、ＩＭＳでは、業務処理要求であるメッセージはメッセージ・キューに格納されるが、ＦＰではこのキューイング・システムをバイパスして、端末からより簡易な待ち行列（回復可能ではない）を介してトランザクションプログラムに送信することができる。これらにより、オンライン応答性を高めている。
【００１９】
【発明が解決しようとする課題】
近年のオンラインシステムは、２４時間３６５日の連続稼働が求められている。従って、バッチ処理をオンライン処理と並行して処理することが望まれる。すなわち、従来のバッチ処理をオンライン処理として再構築することが要請される。一般的には、バッチ処理はＤＢの静的状態を前提として実行されるため、オンライン応答によってＤＢの内容が変化している最中に、バッチ処理そのものを実行することはできない。静的な状態を前提としていた処理を、動的な状態で実行しようとする場合には、連鎖的アボートと同様の事態が生じ得る。
【００２０】
連鎖的アボート(cascading abort)は、トランザクションの一貫性、直列性が失われた場合の弊害である。例えば、ＤＢの値がｘからｙへと更新されたのち、その更新された値であるｙに基づいて複数のトランザクションが実行されたとする。その後、このｘからｙへの更新が取り消されたとする。または、ｙからｚへと更新されたとする。すると、ｙを前提として成立したトランザクションは全て取り消して再実行しなければならなくなる。トランザクションのアボートが生じると、さらに次のトランザクションのアボートを連鎖的に生じさせる。このような事態は避けなければならない。しかし、バッチ処理を日中にオンラインと並行して処理しようとする場合には、このような連鎖的アボートと同様な事態が生じ得る。例えば、前日の最終残高に基づいて行う口座振替を、前日の日中に処理する場合には、前提としていた前日の最終残高が変化する可能性がある。口座振替処理後に口座残高に異動があると、一見、連鎖的アボートが生じる事態と同様の状態となり得る。
【００２１】
このように、バッチ処理を日中のオンライン処理として実行しようとすると、ＤＢが静止していない状態で種々の処理を行う必要があるため、一貫性及び直列性を厳密に管理する必要が生じる。この課題は、口座振替のみならず、種々の応用分野でバッチ処理を日中のオンライン処理として実行しようとする開発での共通した課題である。
【００２２】
連鎖トランザクションモデルは、端末へ応答する処理をコミットさせておき、その後に別のトランザクションを実行することができるため、オンラインの応答性と複雑な処理の実現とを両立させることができる。しかしながら、バッチ処理のオンライン化という点では、処理要求が集中した場合の対策や、上述した連鎖的アボートとなりえる状況への対策が必要となる。また、連鎖トランザクションモデルは標準化されておらず、すべてのトランザクション管理システムで利用できるとは限らない。
【００２３】
上記特開平１０−６９４１８号公報には、連鎖トランザクションモデルを階層化して用いつつ、大域トランザクションにＡＣＩＤ特性を付する旨開示されているが、メンバ・トランザクションのアボートと大域トランザクションの原子性との関係については開示されていない。
【００２４】
オンラインの応答性を確保するには、高速パス（ＦＰ）などの採用が望ましい。しかしながら、ＦＰを用いると、データベースのバッファ数に制限があり、また、キューからの回復ができないなどの一定の制限があるため、例えば、ＡＣＩＤ特性を有する１トランザクションで処理可能な処理量が制限されてしまう。例えば、入れ子トランザクションと同様に１つのトランザクション内で複数の処理を連動させる連動トランザクションについて、ＦＰを採用している場合には、１トランザクションで実行可能な連動回数に制限がある。
【００２５】
【発明の目的】
本発明は、係る従来例の有する不都合を改善し、特に、オンライン処理の応答性を確保しつつ複雑な処理を実現することのできるトランザクション制御システム，方法及びプログラムを提供することを、その目的とする。
【００２６】
【課題を解決するための手段】
本発明では、派生トランザクションモデルを用いる。派生トランザクションは、主取引に付随する業務を実行する。付随業務を処理するためのトランザクションモデルを用意することで、適用業務プログラムのプログラマは、業務処理（主業務）を、オンライン応答に無関係な付随業務を除いて通常のＡＣＩＤ特性を有するトランザクションとしてプログラムを構築し、主業務に付随する付随業務を派生トランザクションとしてプログラムを構築することができる。そして、業務処理を実行するトランザクションは、その実行中に派生トランザクションを起動要求依頼した後、派生トランザクションの処理完了を待たずに端末に応答を返す。
【００２７】
本発明では、端末からネットワークを介して入力される業務処理要求を受信する受信手段と、この受信手段にて受信した業務処理要求を処理する演算手段と、この演算手段の処理結果を記録するファイルとを備えている。
そして、演算手段は、トランザクション実行部と、オンライン応答部と、派生トランザクション管理部とを備えている。
トランザクション実行部は、所定のオンライントランザクション及び所定の派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルのデータ項目をロックし、処理し、前記ファイルに当該処理結果を記録し、当該記録後に前記ロックを解除する。
オンライン応答部は、前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をする。
派生トランザクション管理部は、前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理する。さらに、この派生トランザクション管理部は、前記各トランザクションの実行中に、新たな派生トランザクションの起動要求依頼が出力された際には、当該起動要求依頼を出力したトランザクションを派生起動トランザクションとして、次の制御を行う。すなわち、当該派生トランザクションの起動要求依頼を、当該派生起動トランザクションの原子性に包む制御をする。続いて、当該起動要求依頼された前記派生トランザクションのコミットを待機せずに前記派生起動トランザクションをコミットさせる。
本発明によるトランザクション制御システムでは、前記派生トランザクションは、前記派生起動トランザクションの実行中に起動要求依頼され、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションである。
そして、本発明では特に、前記派生トランザクション管理部は、前記派生トランザクションの起動と開始とを管理する。
すなわち、派生トランザクション管理部は、前記起動要求依頼が出力された際に、当該派生トランザクションの起動要求依頼に関連する派生起動情報を前記ファイルに記録し、当該派生起動情報の記録を、前記派生起動トランザクションの原子性に包む制御をすることで、派生トランザクションの起動を管理する派生起動情報格納制御機能を備える。
さらに、派生トランザクション管理部は、当該起動要求依頼された派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせる機能を備える。
しかも、派生トランザクション管理部は、前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、当該起動要求依頼された派生トランザクションの処理を開始させることで、前記派生トランザクションの開始を管理する直列性管理機能を備えた、という構成を採っている。これにより前述した課題を解決しようとするものである。
【００２８】
オンライン応答部は、業務処理要求をオンライントランザクションとして処理させ、その応答を端末へ出力する。オンライントランザクションは、顧客が使用する端末の操作によって生じた業務処理要求の処理でも良いし、内部的な従来バッチ処理で行っていた処理に相当する業務処理要求でも良い。「処理結果を端末への応答として出力する」というのは、オンライントランザクションの実行の一部として端末（又は擬似的な端末）への出力が要求されている場合に応答を端末に出力するのであって、全てのトランザクションが端末に応答を返すとは限らない。
【００２９】
派生トランザクションは、オンライントランザクションによる業務処理と関連した付随業務を処理する。付随業務は、オンライントランザクションのオンライン応答を行う必要のない業務であり、一般的には主業務に付随する業務であるが、主業務側が付随的で付随業務が実際に必要な処理を行う場合もある。派生トランザクションは、オンライントランザクションの実行中に、プログラムによって起動される。また、派生トランザクションがさらに別の派生トランザクションを起動するようにしても良い。派生起動管理機能は、派生トランザクションのコミットを待機せずに前記派生起動トランザクションをコミットさせる。すなわち、付随業務の完了を待たずに業務処理を完了させる。派生トランザクションがアボートした場合であっても、派生起動トランザクションが取り消されることはない。
【００３０】
このように、本発明では、連鎖トランザクションモデルを、主業務となる業務処理と、付随的な業務処理との区分けに応用している。これにより、オンライン応答に必要な処理をオンライントランザクションで処理し、オンライン応答に必要のない付随処理を派生トランザクションとして処理することで、オンライントランザクションを早期にコミットさせることができる。すなわち、オンラインの応答性を確保しつつ、付随的な業務のみを事後的に派生トランザクションとして処理することで、全体として複雑な処理を行うことができる。
【００３１】
また、状況によっては、派生トランザクションは、派生起動トランザクションとなることができる。この場合、付随的な業務を１トランザクションで処理することなく、派生トランザクションの繰り返しで実行する。この派生トランザクションを繰り返し起動・実行する例では、個々の派生トランザクションは個別にコミットするため、１つのトランザクションが処理する処理量は比較的少なく、そして、コミットによって一旦ロックが解放される。このため、複雑な付随業務を行いつつシステムに高負荷をもたらすことがない。
【００３２】
派生起動トランザクションと、派生トランザクションとからなる処理（派生利用トランザクション）は、ＡＣＩＤ特性を満たさない。すなわち、派生起動トランザクションがコミットしたが、派生トランザクションがアボートされる、という状況はあり得る。一方、派生起動トランザクションがコミットしない場合には、派生トランザクションを実行しない。すなわち、付随業務が必要となる業務処理自体が未成立であるのに、付随業務のみを成立させることはない。業務処理が成立し、付随業務が未成立となった場合には、その付随業務を処理する派生トランザクションを再起動する。これらの仕組みを実現するために、派生トランザクション管理部が、前記派生トランザクションの起動要求に関連する派生起動情報を前記ファイルに格納した後に前記派生起動トランザクションをコミットさせる派生起動情報格納制御機能と、派生起動トランザクションがアボートされる場合には前記派生トランザクションの開始又はコミットをしない制御をする直列性管理機能とを備える。また、好ましい実施形態では、派生起動トランザクションがコミットした後に前記派生トランザクションがアボートした場合には前記派生起動情報に基づいて当該派生トランザクションを再起動させる派生再起動制御機能を備えると良い。
【００３３】
派生起動情報格納制御機能は、派生トランザクションの起動要求があった場合には当該起動要求をしている派生起動トランザクションとこの派生起動トランザクションから派生トランザクションに渡されるデータ等を派生起動情報としてファイルに格納する。この派生起動情報は、正常な処理では利用せず、派生トランザクションがアボートし派生トランザクションのみを再起動する場合に利用される。すなわち、派生再起動制御機能は、派生起動トランザクションがコミットした後に前記派生トランザクションがアボートした場合には前記派生起動情報に基づいて当該派生トランザクションを再起動させる。
【００３４】
派生起動情報格納制御機能等を有する本発明では、一般的な障害発生等によるトランザクションのアボート時の再起動処理とは別に、派生トランザクションの再起動を制御する機能を備えている。これは、派生起動トランザクションと派生トランザクションとを一体と考えた場合にはＡＣＩＤ特性を有しないことから、派生トランザクションのアボート時の取り扱いをより厳格に行うものである。派生トランザクションは、派生起動情報に基づいて起動される。従って、この派生起動情報を耐久性を持った状態でファイルに格納しておくと、当初起動時と完全に同一の状態で派生トランザクションを再起動することができる。また、キューイング・モデルやログによる再起動と比較して、再起動処理の対象の発見が容易で、さらに、派生トランザクションのアプリケーションのバグなどによるアボートであっても、アプリケーションプログラムの修正後の再実行が可能であるなど、取り扱いを柔軟に定めることができる。また、派生トランザクションは付随業務を処理するため、状況によっては再起動が不要である場合も想定できる。このような再起動の要否をオペレータが判断する場合であっても、派生起動情報に派生トランザクションの起動に関する種々の情報を含めることで、再起動の要否を判断する際にオペレータの端末に表示する等の処理が可能となる。
【００３５】
派生トランザクションモデルでは、派生起動トランザクションがコミットし、派生トランザクションがアボートされる事態の発生を許容することで、オンラインの応答性を確保している。従って、派生トランザクションの再起動を厳密に管理できることがシステム運用の安定性に寄与する。
【００３６】
また、本発明では、演算手段が、前記オンライン応答部及び派生トランザクション管理部によって実行が管理されるトランザクションの総量に応じて前記派生トランザクションの起動を制限させる総量制御部を備えるようにすると良い。これにより、派生トランザクションの滞留によってオンライン応答が必要なオンライントランザクションを遅らせることがなくなる。「派生トランザクションの起動の制限」は、例えば、派生起動トランザクションとなる業務処理要求のうち、内部的な業務処理要求についてその入力を待機させたり、また、業務処理要求を実行しつつ、派生トランザクションの起動を中止したり、さらに、派生起動トランザクションの実行をエラーとする処理などを含む。起動が中止された派生トランザクションは、トランザクションの滞留が減少するなどシステムの負荷が軽減された段階で、再起動することができる。
【００３７】
派生トランザクションモデルでは、即時のオンライン応答を行わない付随業務を派生トランザクションとして実行させるため、派生トランザクションは、オンライントランザクションと比較して、実行を待機させることができる時間が長い。このため、総量制御部は、実行されているトランザクションの総量が多い場合には、派生トランザクションの起動を制限させる処理を行う。これにより、オンライン応答が必要なオンライントランザクションの処理を優先する。総量制御部を有する実施形態では、この付随的な業務を処理する派生トランザクションの起動制限により、システムの能力を最大限活用し、複雑な処理を実行しつつ、オンラインの応答性を確保することができる。これにより、バッチ処理の日中処理化を安定して、厳格に実現することができる。
【００３８】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して説明する。本発明は、３つの実施形態を有する。第１実施形態は、派生トランザクションモデルの構造と利用法とを開示する。第２実施形態では、派生トランザクションの特性をＤＢに対するロックを用いて実現する手法を開示する。第３実施形態では、第２実施形態のうち、例外的なデッドロックを回避するための手法を開示する。
【００３９】
【第１実施形態】
図１は第１実施形態によるトランザクション制御システムの構成を示すブロック図である。図１に示す例では、トランザクション制御システムは、端末等１Ａ，１Ｂからネットワーク３を介して入力される業務処理要求を受信する受信手段２と、この受信手段２にて受信した業務処理要求を処理する演算手段４と、この演算手段４による業務処理要求の処理結果を記録するファイル６とを備えている。端末１Ａは、例えば顧客が使用する端末で、ＡＴＭやパーソナルコンピュータなどである。端末１Ｂは内部のオペレータが使用する端末で、例えば営業店端末と呼ぶ。また、コンソール端末２Ａは、システムの運用管理や業務処理要求の入力を指示するコマンドを入力する端末である。業務処理要求は、端末１Ａ，１Ｂ又は２Ａから入力される。図１に示す例では、受信手段２で受信した業務処理要求は、メッセージ入力手段８を介して演算手段４に入力される。メッセージ入力手段８は、業務処理要求であるメッセージを一時的に格納する待ち行列を備えると良い。図１に示す例では、業務処理要求が通信規格等に応じて種々の形式を採用しているとしても、メッセージ入力手段８が入力するメッセージは演算手段４によって解釈可能な形式とする。また、メッセージ入力手段８は、複数のメッセージをブロッキングして一括した入力を行うようにしてもよい。
【００４０】
前記演算手段４は、前記端末等１Ａ，１Ｂから入力される業務処理要求をメッセージ入力手段８から入力されるメッセージに従ってオンライントランザクションとして処理させると共に、当該処理結果を前記端末への応答として出力する制御をするオンライン応答部１０を備えている。また、演算手段４は、オンライントランザクション又は所定の派生トランザクションである派生起動トランザクションの実行処理の一部として起動要求され当該派生起動トランザクションと関連した付随業務を処理する派生トランザクションを管理する派生トランザクション管理部１２を備えている。演算手段４は、オンライントランザクションや、派生トランザクションや、またはバッチ処理を実行するトランザクション実行部１６を備えている。トランザクション実行部１６は、ファイル６に格納された各種のＤＢに対する操作を行う。
【００４１】
端末１Ａから入力される現金の入金や、端末１Ｂから入力される融資に関する情報の登録などは、オンライントランザクションとして処理される。ここでは、オンライントランザクションの実行と並行して実行される一括処理も、オンライントランザクションと呼ぶ。例えばオンライン稼働中の口座振替処理などは、オンライントランザクションである。オンライントランザクションではないトランザクションは、例えば、夜間バッチである。
【００４２】
派生トランザクションは、端末からの業務処理要求としてではなく、他のトランザクションのプログラムから起動要求される。派生トランザクションの起動要求をそのプログラムの実行に従って依頼するトランザクションを、ここでは派生起動トランザクションと呼ぶ。そして、派生起動トランザクションによって起動された派生トランザクション（Ｔ１）が、さらに別の派生トランザクション（Ｔ２）を起動することがある。この場合、派生トランザクション（Ｔ１）は派生起動トランザクションである。
【００４３】
オンライントランザクションは、オンラインでの応答に必要な処理を行い、そして、付随処理の必要性を判定し、付随処理が必要な場合には派生トランザクションの起動要求を依頼する。派生トランザクションの起動要求依頼があった場合には、派生トランザクション管理部１２の派生起動管理機能２０は、前記派生トランザクションのコミットを待機せずに前記派生起動トランザクションをコミットさせる。派生起動管理機能が、派生トランザクションの完了を待たずに派生起動トランザクションをコミットさせるため、オンライントランザクションを早期に完了させ、ロックの解放を促し、そしてオンラインの応答性を良好に維持する。すなわち、業務処理要求を要求した端末１Ａ，１Ｂは、付随処理の完了を待たずにオンライントランザクションの処理結果を得ることができる。派生起動管理機能２０が、派生トランザクションのコミットを待機せずに派生起動トランザクションをコミットするため、派生起動トランザクションのコミットの後に派生トランザクションがアボートされる可能性がある。本実施形態では、派生トランザクションのアボートがあった場合の再起動を制御する機能を具備することで、派生起動トランザクションと派生トランザクションとを有する処理の実際上の原子性と特別な直列性とを確保している。
【００４４】
図１を参照すると、派生トランザクション管理部１２は、前記派生トランザクションの起動要求に関連する派生起動情報を前記ファイルに格納した後に前記派生起動トランザクションをコミットさせる派生起動情報格納制御機能２２と、派生起動トランザクションがアボートされる場合には前記派生トランザクションの開始又はコミットをしない制御をする直列性管理機能２４と、派生起動トランザクションがコミットした後に前記派生トランザクションがアボートした場合には前記派生起動情報に基づいて当該派生トランザクションを再起動させる派生再起動制御機能２５とを備えている。
【００４５】
派生起動情報は、派生起動トランザクションから渡されるデータや、付随業務の種類や、派生起動情報のファイルへの格納位置や、派生トランザクションの起動時刻（エントリー時刻）など、派生トランザクションの起動や管理に必要な情報である。派生トランザクションを実行するための派生メッセージは、この派生起動情報又はその元となる各データに基づいて作成される。派生トランザクションは派生トランザクション管理部１２によってその性質及び実行が管理される。ファイル６に格納される派生起動情報は、派生トランザクションがアボートした場合の再起動に用いられる。
【００４６】
派生起動情報格納制御機能２２は、派生トランザクションの再起動を確実且つ容易とするために、派生起動情報を格納する。直列性管理機能２４は、派生起動トランザクションがアボートされた場合に、派生トランザクションが起動又は実行される事態の発生を防止する。派生トランザクションは派生起動トランザクションがコミットした場合に開始又は実行されるため、派生トランザクションがアボートされた場合には、派生起動トランザクションは既にコミットしている。従って、派生起動トランザクションを再起動する必要なく、派生トランザクションのみを再起動すればよい。派生再起動制御機能２５は、派生トランザクションの再起動要求等を受信したときに、ファイル６に格納された派生起動情報に基づいて、派生トランザクションを再起動する。
【００４７】
このように、本実施形態では、派生起動トランザクションと派生トランザクションとは次のように定義される。
（１）個別ＡＣＩＤ
派生起動トランザクション、派生トランザクションはそれぞれＡＣＩＤ特性を満たす。派生トランザクションは、派生起動トランザクションとして、さらに別の派生トランザクションを起動することもできる。
（２）拡張された直列性
派生起動トランザクションがコミットした場合にのみ派生トランザクションはコミットする。派生起動トランザクションがコミットした場合に、派生トランザクションの動作が開始するとしても良い。
（３）拡張された原子性
派生トランザクションのアボートは派生起動トランザクションに及ばない。
（２）と（３）によると、一方通行の原子性という性質が明らかになる。派生トランザクションのコミットの条件の一つは派生起動トランザクションのコミットである。一方、派生起動トランザクションは、派生トランザクションの運命に関わらずコミットする。派生起動トランザクションと派生トランザクションを一体とした派生利用トランザクションを考えると、派生利用トランザクションは原子的でない。（３）拡張された原子性の効用は、派生起動トランザクションを早期にコミットし、そのロックを解放させ、派生起動トランザクションの応答性を高める点にある。派生トランザクションをリアルタイムに近い状態で実行することができるため、従来バッチ処理で行っていたような処理を派生トランザクションとしてオンライン応答に多少遅れて、しかしほぼ同時に、他のオンライントランザクションと並行して実行することができる。
（４）拡張された隔離性
派生起動トランザクションが扱ったデータやその結果を派生トランザクションに渡すことができる。これは、派生トランザクションの起動の仕方に依存する。派生トランザクションの結果を派生起動トランザクションが待機することはない。派生起動トランザクションから派生トランザクションへ渡されるデータは、他のトランザクションからは隔離されている。一方、派生起動トランザクションのコミットによって、そのリソースは、派生トランザクションを含めた他のトランザクションからアクセス可能となる。
（５）拡張された一貫性（オプション）
派生起動トランザクションはＡＣＩＤ特性を満たすから、そのトランザクションによってデータベースの内容等はアプリケーションにとって一貫性のある状態となる。しかし、派生トランザクションモデルでは、この一貫性は、システムレベルの一貫性であって、業務レベルでの一貫性である必要はない。すなわち、派生トランザクションモデルでは、業務レベルでの一貫性を、付随業務を処理する派生トランザクションの実行で確保するようにしてもよい。派生トランザクションを活用する一例としては、業務レベルで失われる一貫性を、システムレベルでは厳格に一貫性ある状態とするために、業務レベルでの中間的なデータを耐久性のある状態で記録するデータ構造を用いることができる。例えば、端末へのオンライン応答に必要なデータと、オンライントランザクションの処理を行った結果、数秒後や次の日までに整理又は最適化しておくべきデータとがある場合には、派生起動トランザクションは、オンライン応答に必要なデータを更新し、次の日までに必要なデータについては、業務レベルでの一貫性に欠ける中間的なデータとして耐久性を持って格納する。そして、派生起動トランザクションは、この中間的なデータを格納した段階でコミットする。次の日までに整理等が必要なデータについては、派生トランザクションを用いてオンライン応答の完了後に処理することができる。
【００４８】
図２は、派生トランザクションの性質を説明する説明図であり、図２（Ａ）は、派生起動トランザクションから派生トランザクションの起動要求がなされる例を示す図である。図２（Ａ）に示すように、業務処理要求があると、オンライントランザクションは派生起動トランザクションＳ１として実行され、派生トランザクションを派生起動要求した上でコミットＣ１する。その後、派生トランザクションＳ２が実行され、コミットＣ２する。
【００４９】
オンライントランザクション制御システムを用いて派生トランザクションを管理する方法は、端末等から入力される業務処理要求をオンライントランザクションとして実行させる工程（Ｓ１Ａ，オンライン応答部１０）と、このオンライントランザクション実行処理の一部として派生トランザクションの起動が要求された場合には当該派生トランザクションの起動に必要な派生起動情報を前記ファイル６に格納する工程（Ｓ１Ｂ，派生起動情報格納制御機能２２）とを備える。さらに、派生トランザクション管理方法は、派生トランザクションの実行開始又はコミットを待機せずに当該派生トランザクションを起動したオンライントランザクションをコミットさせる工程（Ｃ１，派生起動管理機能２０）と、オンライントランザクションがアボートした場合には前記派生トランザクションの開始又はコミットをさせない制御をする工程（Ｓ２Ａ，直列性管理機能２４）とを備える。
【００５０】
図２（Ｂ）は、派生起動トランザクションが連動トランザクションである場合を示す図である。１つのトランザクション内で複数の業務を実行する仕組みを、ここでは連動と呼ぶ。連動起動業務Ｓ３Ａと連動受動業務Ｓ３Ｂとは１つのトランザクションとして実行されるため、双方が成功するか否かの原子性が保証される。勘定系システムを例にすると、連動起動業務Ｓ３Ａは、例えば電気料の引落であり、この場合、連動受動業務Ｓ３Ｂは、普通預金からの出金である。連動トランザクションは１つのトランザクションとして実行されるため、電気料の支払に成功する一方、その金額が普通預金から出金されていないといった一貫性のない状態は発生しない。図２（Ｂ）に示す例では、連動起動業務Ｓ３Ａが連動受動業務Ｓ３Ｂに普通預金の出金を依頼し、連動受動業務Ｓ３Ｂでは出金を行うと連動起動業務Ｓ３Ａに処理を戻す。連動戻りを受けた連動起動業務Ｓ３Ａは、他の処理を行った後にコミットする。そして、普通預金の口座残高に異動があった場合に、即時にオンライン応答する必要のない付随業務がある場合には、連動受動業務Ｓ３Ｂは、派生トランザクションＳ４を起動する。
【００５１】
図２（Ｃ）は、派生トランザクションが自らを派生トランザクションとして起動要求する例を示す図である。本実施形態では、派生トランザクション自身が派生起動トランザクションとなることができる。また、派生トランザクションは、派生起動トランザクションを派生トランザクションとして起動することもできる。図２に示す例では、派生起動トランザクションのコミット後に派生トランザクションがアボートした場合には、前記派生起動情報に基づいて当該派生トランザクションを再起動させる。この図２に示す各態様を組み合わせて利用することで、種々の特性を有する業務処理を実現することができる。
【００５２】
図１に示す構成及び図２に示す仕組みは、所定のプログラムを演算手段が実行することで実現することができる。演算手段４は、所定のプログラム（指令）に従って各種の演算を行うＣＰＵを備えている。ＣＰＵは、業務処理要求（メッセージ）に従ってオンライントランザクションをスケジュール（ルーティング）すると共に、その実行結果を端末１Ａ，１Ｂに戻すための指令や、派生トランザクションの性質を管理するための指令等のオンライントランザクション制御用プログラムを実行することで、図１に示すオンライン応答部１０や、派生トランザクション管理部１２として動作する。これらのプログラムはＣＰＵに併設されたプログラム記憶部に格納される。また、基本的な入出力を行うオペレーティングシステムや、データベースの管理やログによる復帰や、一般的なトランザクションの管理や、ＤＢのロックなどを行うプログラム群についても、このプログラム記憶部に格納されている。
【００５３】
このようなトランザクション制御プログラムは、ＣＰＵ（演算手段）を動作させる指令を備える。例えば、トランザクション制御プログラムは、端末等から入力される業務処理要求をオンライントランザクションとして実行させる指令と、このオンライントランザクションの実行処理の一部として派生トランザクションの起動が要求された場合には当該派生トランザクションの起動に必要な派生起動情報を前記ファイルに格納させる指令と、派生トランザクションの実行開始又はコミットを待機せずに当該派生トランザクションを起動したオンライントランザクションをコミットさせる指令と、オンライントランザクションがアボートした場合には前記派生トランザクションの開始又はコミットさせない制御をする指令とを備えている。演算手段４は、これらの指令を実行することで、派生起動管理機能２０や、派生起動情報格納制御機能２２として動作する。また、トランザクション制御プログラムは、派生起動トランザクションがコミットした後に前記派生トランザクションがアボートした場合には前記派生起動情報に基づいて当該派生トランザクションを再起動させる指令を備える。その他、トランザクション制御システムや、オンラインシステムにて実現すべき各手段、各部又は各機能や、フローチャートの各工程に応じた指令を備えることで、ＣＰＵは種々の機能を有する演算手段４として動作する。
【００５４】
トランザクション制御プログラムは、磁気テープ（ＭＴ）やディスク等の記録媒体１１Ａに格納されて搬送され、媒体読取部１１によって読み取られる。記録媒体に格納されていたトランザクション制御プログラムは、媒体読取部１１にて読み取られた後、プログラム記憶部に格納される。また、他のホスト装置から通信回線を経由してプログラム記憶部にプログラムを提供することもできる。
【００５５】
プログラムについて、ＣＰＵ（演算手段）を「動作させる指令」というときには、各指令のみでＣＰＵを動作させる指令と、プログラム記憶部に予め格納されているオペレーティングシステム等の他のプログラムに依存して当該ＣＰＵを動作させる指令とのいずれかまたは双方を含む。ここでは、「オペレーティングシステム」は広義に解釈している。トランザクションマネージャや、データベースマネージャ等を含む。従って、ＩＭＳ，ＦＰ及びＳＡＩＬなども便宜上ＯＳと考える。
【００５６】
派生起動情報格納制御指令は、派生起動情報の格納先をオペレーティングシステムに引き渡す指令のみでもよい。このように、当該トランザクション制御プログラムを記憶する記録媒体１１Ａであって、当該プログラムをユーザへ搬送する用途の記録媒体１１Ａには、例えば「派生起動情報の格納先をオペレーティングシステムに引き渡す指令」のみが格納され、実際のデータの格納等はオペレーティングシステムによって行われる場合がある。これは、動作させようとするコンピュータのオペレーティングシステム等との関係で定まる。この点、通信回線を介してプログラム（指令）を提供する場合も同様である。
【００５７】
このプログラムとシステム又は方法、搬送媒体等に関する説明は後述する実施形態においても同様である。特に、同一の名前が付されている機能、工程、指令のそれぞれが対応する点は、各実施形態においても同様である。例えば、トランザクション制御プログラムは、派生起動情報格納制御機能を実現するには、その機能を実現するための派生起動情報格納制御指令を備える。
【００５８】
次に、オンラインシステムでの派生トランザクションの利用法を説明する。図３（Ａ）は派生トランザクションの利用法に応じた端末応答等を説明するための説明図である。端末１（１Ａ又は１Ｂ）は、業務処理要求を演算手段４に入力する。派生トランザクションモデルでは、主業務をオンライントランザクションＳ１１として実行し、付随業務を派生トランザクションＳ１２として実行する。すなわち、トランザクション実行部１６は、前記業務処理要求に関連した付随業務を前記派生トランザクションとして実行する。図３（Ａ）に示す例では、主業務は付随業務を派生起動しているため、派生起動トランザクション（派生起動Ｔ）である。派生起動トランザクションと派生トランザクションとは個別にコミットする。派生起動トランザクションは、付随業務の完了を待機せずに端末１に応答を返す。
【００５９】
勘定系システムを例とすると、図３（Ａ）に示す利用法としては、口座を新設した場合の名寄せ処理がある。勘定系システムで顧客を単位とした口座体系を採用する場合、営業店２０１で口座を有する顧客が営業店２０２でも口座を新設した場合には、この２つの口座を関連させる名寄せ処理を行う。名寄せ処理は、例えば、同一氏名で住所が同一の場合に行う。このため、新規口座開設があると、その口座氏名と同一氏名の口座を全営業店の全口座から探索しなければならない。そして、口座の開設自体は、名寄せ処理を行わなくても完了させることができる。このため、口座の開設処理をオンライントランザクションとして構築し、名寄せ処理をこの口座開設処理の付随業務として構築する。これにより、口座開設を早期にコミットさせつつ、バッチ処理を用いずに名寄せ処理を行うことができる。
【００６０】
図３（Ａ）に示す他の利用法として、用途に応じたデータの二重化を行う処理がある。例えば、融資に関する情報を全営業店の通し番号である融資先番号を単位として融資マスタＤＢに格納しているとする。この融資マスタＤＢには、融資の実行予定日を指定した予約オペレーションにより、融資先番号を単位として予約セグメントが作成される。融資の実行に本部の決裁が必要な場合には、稟議書作成オペレーションにより稟議書を作成し、本部に送付する。本部では、融資の内容に応じて決裁又は否認のオペレーションを行う。営業店では、融資の実行予定日に、本部決裁された案件をあわせて融資実行のオペレーションを行い、融資先番号で特定できる融資先の口座に入金する。
営業店では、融資実行のオペレーションを行うために、その日に実行すべき案件の一覧を照会する必要があるが、融資マスタＤＢから照会を行うと、融資先番号は店別でなく全店通し番号で採番されているため、全融資先を検索しなければならず、この場合、分単位の処理時間が必要となってしまう。そこで、営業店での照会用に、融資マスタＤＢとは別の稟議ＤＢを構築することで、予約セグメント等の二重化を行う。稟議ＤＢは営業店の店番単位に、実行予定日順に予約セグメントを保有するデータ構造とし、店別の照会を短時間で行えるようにした。稟議ＤＢへの予約セグメントの登録は、店番の下に多くのセグメントが存在し、かつ、追加される場所は実行予定日によって異なり、常に最終位置とは限らないため、必ずしも短時間で終了するというわけではない。一方、主業務である予約オペレーションは短時間で終了させたい。このため、本実施形態では、予約オペレーション等を主業務とする。そして、稟議ＤＢへの予約セグメントの登録を付随業務として派生トランザクションで実行することとした。図３（Ａ）に示す例では、ステップＳ１１にて融資マスタＤＢへ予約セグメントを登録するための予約オペレーションを実行し、付随業務を派生トランザクションＳ１２として起動する。予約オペレーションを実行する派生起動トランザクションＳ１１は、付随業務Ｓ１２のコミットを待たずにコミットする。これにより、予約オペレーションは短時間で終了する。付随業務Ｓ１２では、予約オペレーションに少し遅れて、稟議ＤＢへの予約セグメントの登録処理を行う。
【００６１】
図３（Ｂ）は、付随業務として先日付完結処理システムでの取消再カットメインを実行する例を示す説明図である。先日付完結処理システムは、従来バッチ処理で行っていた口座振替等の決済をオンライントランザクションとして日中に処理するための手法であり、その詳細は同一出願人により別途出願されている。ここでは、その概要を説明する。口座振替等の口座処理は、勘定日を有している。先日付完結処理システムでは、現在の残高に基づいて次営業日以降（先日付）の勘定日の口座処理を実行し、その勘定日の残高を算出しておく。このため、先日付完結処理システムでは、演算日の残高と、将来の勘定日の残高とを保有する。
例えば、１０日に３０，０００の残高があり、１０日にて１１日を勘定日とする電気料の引落１０，０００を実行し、１０日の残高を３０，０００としたまま、１１日（先日付）の残高を２０，０００とする。１０日に現金出金等の口座処理要求（業務処理要求）があった場合には、１０日の残高である３０，０００を参照する。一方、日付が変更された場合には、１１日の残高を参照する。１１日の残高はすでに電気料の引落が完了した残高となっているため、日付変更時になんら処理を行う必要がない。このため、先日付完結処理は、先日付で口座振替等を処理した時点で、その処理が完結している。
【００６２】
さて、電気料の引落を先日付にて処理した後、１０日の口座残高に異動があったとする。例えば２５，０００の出金があるとする。１０日の残高は３０，０００であるため出金可能で、出金後は５，０００となる。１１日の残高については、２０，０００から２５，０００減算すると、マイナス５，０００となる。残高がマイナスとなるのは自動融資等の契約によらない限り、業務上ありえないため、１１日の残高を不足として電気料の引落を取り消さなければならない。電気料の引落を取り消すと、１１日の残高は５，０００となる。続いて、この未成立であった電気料の引落がある場合に、例えば１０日を勘定日として６，０００の入金があると、１１日の残高は１１，０００となり、電気料の引落が可能となる。この場合、勘定日の残高から電気料を口座振替するという契約に従って、電気料の引落を再実行（再カット）する。
【００６３】
このように、先日付完結処理では、その口座残高を最終残高とした場合の先日付の決済を実行する。口座に異動があった場合には、再度先日付の決済を調整する。これにより、口座振替等の決済の夜間バッチを日中に処理することができる。この口座振替の日中処理を、ここではセンター一括処理ともいう。センター一括処理は、バッチ処理ではなく、コンソール端末２Ａからのコマンド入力により開始されるオンライン処理である。
【００６４】
オンライントランザクションによる当日の口座残高の異動と、この異動によって生じる取消、再カットとを１つのトランザクションで実行しようとすると、種々の弊害が生じる。第１に、１つのトランザクションの実行時間が長くなるため、オンラインの応答性が悪化する。第２に、取消や再カットすべき口座処理要求の数が予測できないため、例えば連動回数の制限などによって実際上処理できなくなる可能性がある。このため、先日付完結処理では、派生トランザクションモデルの採用が望ましい。
【００６５】
上述したように、派生トランザクションモデルでは、拡張された一貫性を用いることができる。派生起動トランザクションはＡＣＩＤ特性を満たすから、そのトランザクションによってデータベースの内容等はアプリケーションにとって一貫性のある状態となる。しかし、この一貫性はシステムレベルの一貫性であって、業務レベルでの一貫性である必要はない。
【００６６】
業務レベルでの一貫性に欠けるデータは、例えば、先日付での出金可能額のマイナスを許容したデータ構造である。出金可能額がマイナスである状態は、最終的には、マイナスの勘定日を迎えるまでに解消すれば良い（実際には、派生トランザクションによって数秒以内にマイナスの状態が解消される）。先日付完結処理での派生トランザクションモデルの利用方法を図３（Ｂ）に示す。上記の例で、１０日に２５，０００の出金要求があると、主業務（オンライントランザクション）Ｓ１７Ａは１０日の残高を参照して２５，０００の出金を行い、１０日の残高と１１日の残高を更新する。１１日の残高はマイナス５，０００となる。そして、口座残高に異動が生じたため、取消再カットメインを派生トランザクションとして起動する。マイナス５，０００をファイルに格納し、取消再カットメインＳ１８Ａを派生トランザクションとして起動すると、その後の処理はオンライン応答とは無関係であるため、主業務Ｓ１７Ａはコミットし、出金処理を完了させる。すなわち、取消再カットメインの完了を待たずに現金出金処理をコミットさせる。先日付の決済の再調整は、口座残高の異動という主業務に対する付随業務として、派生トランザクションで処理するのである。
【００６７】
取消再カットメインＳ１８Ａでは、１１日のマイナス５，０００という残高に基づいて、取り消すべき口座処理の特定を行う。１１日に成立している口座処理が電気料引落のみであるとすると、取消再カットメイン（派生Ｔ）は、電気料引落の取消を派生トランザクションとして起動する。ステップＳ１７Ｂでは、電気料引落の取消を行い、１１日の残高を更新する。電気料引落の取消処理Ｓ１７Ｂは、口座に異動が生じたため、再度取消再カットメインＳ１８Ｂを派生トランザクションとして起動する。取消再カットメインＳ１８Ｂは、１１日の口座残高がプラスとなったため取り消しの対象はないと判定し、また未成立の取引も存在しないため処理を完了する。
【００６８】
先日付完結処理システムでは、派生トランザクションモデルを採用し、当日の口座処理要求に関してはオンライントランザクションとして処理し、口座の異動に伴う先日付の口座処理の調整については、派生トランザクションを用いる。これにより、オンラインの良好な応答性を確保しつつ、口座振替等の日中処理を実現する。この先日付完結処理システムは、先日付の決済には決済完了性がない（勘定日を迎えるまで取り消しが可能である）ことを利用して、口座処理間の優先順位に従った取消再カットを行うことで、口座処理を優先順位に従って並べ替えることができる。
【００６９】
図４は、優先順位に従った口座処理の入れ替えを行う取消再カットメインの構成を示す説明図である。図４に示した技術の詳細は、同一出願人による特願２００１−０７８３０６号の「先日付完結処理システム及びその方法」の明細書及び図面に記述されている。ここでは、その概要を説明する。図３を参照すると、取消再カットメインは、主業務を起動し、さらにその主業務は取消再カットメインを起動している。この派生トランザクションの繰り返し起動による処理を、スパイラル処理と呼ぶ。各取消再カットメインＳ１８Ａ，Ｓ１８ＢはそれぞれＡＣＩＤ特性を満たす独立したトランザクションであるから、内部的な情報を使用して繰り返しによる連続的な処理を実現することはできない。このため、スパイラル処理では、取消再カットメインの判定及び処理の連続性を保つための派生管理フラグを用いる。
【００７０】
図４を参照すると、派生起動トランザクションは図２（Ｂ）に示すような連動取引を利用している。連動起動処理では、口座処理の取消や、再カットを行う。この口座処理の取消と連動して、連動受動処理側では普通預金への入金や、出金を行う。例えばＳ３１では電気料引落の取消を行い、自動振替を管理するＤＢに決済不能である旨を格納する。そして、連動受動処理では、その勘定日の普通預金の残高に取消金額を入金する。電気料引落の取り消しと、普通預金への取消金額の入金とは連動するため、１トランザクションとして実行される。従って、取消及び入金とは原子性を有する。この連動起動処理Ｓ３１及び連動受動処理Ｓ３２は、連動受動処理が成立し、その成立に応じた処理が起動処理側で完了したときに、同期点に達する（Ｃ３５）。
【００７１】
取消再カットメインは、派生管理フラグと、マイナスを許容した先日付の残高明細や、成立した取引を記録する取引明細や、未成立の取引を記録する残不足明細などのセグメントを参照して、口座を最適化（または、業務としての一貫性の回復）のためにどのような処理をすべきかを判定し、その判定結果に従って、取消処理や、修正再カット処理や、再カット処理を派生トランザクションとして起動する。取消再カットメインは、まず、先日付の勘定日にて出金可能額がマイナスとなっているか否かを判定する。そして、マイナスとなっている場合には（分岐Ｂ１）、マイナスとなっている勘定日での優先順位が最も低い口座処理要求を取り消す取消処理を、派生トランザクションとして起動する。取消処理を派生起動すると、取消再カットメインは同期点に達し（Ｃ３１）、終了する。
【００７２】
連動起動処理Ｓ３１及び連動受動処理Ｓ３２の連動によって取消が行われ、取り消された金額分口座残高が更新された後に、取消再カットメインは再度出金可能額を確認し、マイナスであれば、この時点で最も優先順位の低い口座処理要求の取消処理を派生起動し、その後コミットする（Ｃ３１）。この取消処理の繰り返しを、ここでは取消スパイラルＳＰ１と呼ぶ。取消スパイラルＳＰ１は、出金可能額のマイナスがなくなると終了する（分岐Ｂ２）。
【００７３】
口座残高が増額された場合や、出金可能額のマイナスがなくなった場合には（分岐Ｂ２）、修正再カットの可否を判定する。修正再カットは、先日付の勘定日について、成立済みの口座処理と未成立の口座処理とを入れ替えることで、その勘定日にて成立させる口座処理を予め定められた優先順位の順序とする処理である。具体的には、未成立の口座処理要求のうち最も優先順位の高い口座処理要求を最高位の口座処理要求とし、この口座処理要求よりも優先順位が低く成立済みの口座処理要求で利用している出金額を合計し、さらに残高を加算することで修正出金可能額を算出する。最高位の口座処理要求が修正出金可能額よりも小さければ（分岐Ｂ３）、最高位の口座処理要求の修正再カットを実行する（Ｓ３４）。修正再カットを実行すると、その勘定日の残高はマイナスとなる。従って、次に起動される取消再カットメインでは、出金可能額がプラスとなるまで優先順位の低い順に成立済みの口座処理要求を取り消す。
【００７４】
修正再カットを繰り返すと、取引明細に格納された口座処理要求の優先順位が、残不足明細に格納された口座処理要求群の優先順位よりも高くなる。この状態では、修正出金可能額の算出ができなくなるため、修正再カットは不要と判定される（分岐Ｂ４）。
【００７５】
修正再カットができない口座処理要求が、再カットされることはない。再カットの判定では、修正再カットの対象となっていない口座処理要求の再カットを検討する。例えば、修正再カットは取消を前提とするため、口座処理の取消を行わない当日の口座処理要求の再カットや、修正再カットを行わないと判定された優先順位の低い口座処理要求の再カットの可否を判定する。再カットは、処理対象とする勘定日（例えば、演算日当日）を勘定日とする未成立の口座処理要求のうち、最も優先順位の高い口座処理要求の取引金額（出金額）と対象勘定日の出金可能額とを比較する。取引金額が出金可能額より小さければ、再カット可能であるため、その口座処理要求の再カットを派生トランザクションとして起動し、コミットする（Ｃ３３）。
【００７６】
連動起動処理Ｓ３７及び連動受動処理Ｓ３８は連動して再カット処理を行い、同期点に達した後に再度取消再カットメインが起動される。出金可能額にマイナスがなく、修正再カットが完了し、再カットの対象がない場合には、取消再カットメインは処理を完了する。一般的には、残高が減少した場合には取消スパイラルＳＰ１が動作し、残高が増加した場合には修正再カット及び再カットスパイラルＳＰ２が動作する。取消再カットメインが、派生トランザクションを活用して口座処理の最適化を順次実行するため、先日付での取消の発生を前提とした先日付完結処理を厳格に実行することができ、さらには、優先順位による決済という複雑な処理を安定して実現することができ、また、先日付完結処理であるため、優先順位に基づいた処理を行いつつ、２４時間連続稼働を行うことができる。さらに、取消再カットメインが、口座残高に異動が生じるごとに口座処理要求の優先順位に基づいた最適化を実行するため、バッチ処理と比較して、口座処理要求の実行順序が限定されることがなくなる。
【００７７】
この口座処理の並べ替えや、先日付を用いた夜間バッチの日中処理化は、勘定系システムに関わらず、種々のオンラインシステムで利用可能である。例えば、チケットや宿泊施設の予約に関する優先順位の反映や、商品販売をインターネット等を介して行う場合の売価や商品の変更や、注文があった場合の各種の情報の更新などである。また、販売と在庫管理と需要予測と発注とを関連させたシステムでは、販売と在庫管理とを連動させたオンライントランザクションとして実行し、発注に必要な処理を派生トランザクションとして起動する。発注の有無は販売とは無関係であるため、オンライントランザクションは在庫を参照して販売を記録した時点でコミットする。派生トランザクションは、在庫数や需要予測に応じて発注の有無を判定する。この場合、販売及び在庫管理が業務処理（主業務）であり、発注が付随処理（付随業務）となる。また、販売の成立によって、配送や請求の手配が必要となる。販売をトリガとする配送や請求の手配も、派生トランザクションの起動とすることもできる。このように、オンラインシステムで応答性の確保と、複雑な処理の自動化と、処理の厳密さとを同時に達成すべき場合には、本実施形態による派生トランザクションモデルを利用することができる。
【００７８】
本実施形態による派生トランザクションモデルを利用すると、派生起動トランザクションの実行によって業務上の一貫性に関して中間的なデータが生じる場合には当該中間的なデータについて耐久性を持った状態で前記ファイル６に格納し、この業務処理要求の実行によって生じた業務上の一貫性に関する中間的な状態を解消して業務上の一貫性を保つための判定及び実行を前記派生トランザクションとして実行する。これにより、オンラインの応答性の向上と複雑な処理の厳密な実行とを両立させることができる。
【００７９】
図５は端末折り返し連続処理に派生トランザクションを用いた例を示す説明図である。派生トランザクションは、付随業務の処理に用いる。付随業務の特殊な例として、端末折り返し連続処理がある。端末折り返し連続処理は、端末から入力されたトランザクションの処理がシステムの各種制限の関係で端末とのデータの送受信を繰り返さなければ完成しない処理に関連する。端末とのデータの送受信を行うと、一般に演算速度よりも通信速度の方が遅いため、ＣＰＵを通信の間待機させなければならなくなる。
【００８０】
例えば、積立定期の出金処理では、毎月１０年間の積立で１２０明細となるなど支払うべき明細数が多くなることがある。この場合、システム資源に制約があるため、１トランザクションで全明細を処理できるとは限らない。従って、例えば、１トランザクションで５明細処理することとする。５明細の処理が完了する毎に端末にダミー応答を送信し、端末からの継続処理要求を受信したら、また５明細処理することを繰り返す。しかし、端末とホストのデータ送受信には、一般的に２秒程度を要するため、例えば１００明細処理するのには、４０秒（２秒×２０回）必要になる。ＣＰＵが５明細を処理するのに要する時間は、メッセージの送受信を除くと０．１秒程度である。
【００８１】
このため、図５に示す例では、端末折り返し連続処理となる業務処理要求を主業務とする場合、実際に利息を含めた支払内容の算出を付随業務と考えて、派生トランザクションの繰り返しを用いることで、端末との通信によるレスポンスの悪化を防止する。すなわち、端末折り返し連続処理では、付随業務側が実際の処理を行い、主業務は端末応答を受け持つ。図５に示す例では、積立定期の出金要求を受信すると、主業務Ｓ１３Ａは、支払うべき明細を特定して、最初の５明細の支払処理を行う。そして、主業務Ｓ１３Ａは、利息を含めた支払内容を取引明細としてファイル６の取引明細に登録する。主業務Ｓ１３Ａは、さらに、図５に示す端末制御ＤＢの処理中フラグをＯＮとする。そして、主業務Ｓ１３Ａは、支払処理Ｓ１４Ａを派生トランザクションとして起動する。端末に対しては、まだ処理中であるとの情報をセットしたダミー応答を送信する。ここで、主業務Ｓ１３Ａは同期点に達する。
【００８２】
支払処理Ｓ１４Ａは、主業務Ｓ１３Ａから渡された支払うべき明細のキーをもとに、５明細の支払処理を行う。利息を含めた支払内容は、上記取引明細に計上し、更新する。そして、同一の処理を行う支払処理Ｓ１４Ｂを起動する。ステップＳ１４Ｂでは、ステップＳ１４Ａと同様に、支払処理Ｓ１４Ａから渡された支払うべき明細のキーをもとに、次の５明細の支払処理を行う。これを繰り返し、支払処理Ｓ１５にて支払処理が完了すると、端末制御ＤＢ７の処理中フラグをＯＦＦにする。
【００８３】
支払処理はＡＣＩＤ特性を有する派生トランザクションとして繰り返し起動されている。これとは別に、端末から状況確認を受信すると、主業務Ｓ１３Ｂは端末制御ＤＢ７をチェックする。端末制御ＤＢ７の処理中フラグがＯＮであれば、ダミー応答を端末に送信する。さらに、状況確認要求を受信し、端末制御ＤＢ７の処理中フラグがＯＦＦとなっている場合には、主業務Ｓ１６は、取引明細から支払伝票への印字データを作成し、送信する。
【００８４】
このように、端末折り返し連続処理では、トランザクション実行部１６は、業務処理要求を処理する主業務トランザクションが派生トランザクションを起動し（Ｓ１３Ａ）、派生トランザクションは処理対象が無くなるまで当該派生トランザクションを繰り返し起動する（Ｓ１４Ａ，Ｓ１４Ｂ，Ｓ１４Ｃ，Ｓ１４Ｄ，Ｓ１５）。一方、主業務トランザクションは前記派生トランザクションの繰り返し起動によって処理が完了するまで前記端末にダミー応答を繰り返す（ステップＳ１３Ｂ）。派生トランザクション（支払処理）の繰り返し起動により処理対象の処理が完了した後に、前記主業務トランザクションは前記端末に応答を返す。
【００８５】
この図５に示す例では、例えば１００明細で派生トランザクションが１９回実行され、その所要時間は１．９秒（０．１秒×１９回）となり、ダミー応答を送信してから次の要求（状況確認）を受信するまでの２秒の間に全ての支払処理は完了し、全体のレスポンス時間は４秒ということになる。これは、端末への応答を行う場合の１／１０である。
【００８６】
また、連続した多数の処理を行う場合に、派生トランザクションを用いることでオペレーションを簡略化し、全体的な処理速度の向上を図ることもできる。例えば、ある処理を実際に実行させるには管理者の承認が必要な業務がある。例えば、為替振込処理について、管理者の承認が必要であるとする。この場合、その処理の内容を電文ＤＢに登録しておき、管理者の承認を得た段階で、実際の振込を行う。承認を得たことを個別に通知すると、振込件数分のオペレーションと端末とのデータの送受信が必要となる。一方、振込全件を１トランザクションで実行しようとすると、処理時間が長くなり、システムのリソース不足が生じる可能性もある。このため、派生トランザクションを利用する。
【００８７】
顧客から振込依頼書を受け付けると、オペレータは、振込依頼書に基づいて振込内容登録のオペレーションを行う。この時点では、実際の振込は行わない。この振込内容登録の内容は、伝票に印字される。振込内容の登録数がある程度まとまった時点で、オペレータは管理者の承認を求める。管理者は、振込依頼書と伝票の印字内容とが一致していることを確認し、伝票に検印を行う。伝票に検印されると、オペレータは、承認通知処理を行う。この承認通知処理により、振込処理が実行される。承認通知処理は、最初の電文番号と件数を入力することで、１オペレーションで最大２２件までの振込を処理する。
【００８８】
承認通知処理では、まず、オンライントランザクションとして、入力された最初の電文番号で電文ＤＢを読み込み、正当であれば入金処理を行った後に、次の電文番号をセットして、承認通知処理を派生トランザクションとして起動する。派生された派生トランザクションでは、前処理から渡された電文番号に基づいて同じ処理を行い、次の電文番号をセットして、派生トランザクションを起動する。この図２（Ｃ）に示すような派生トランザクションを入力された件数に達するまで繰り返すことで、１度のオペレーションで最大２２トランザクションを実行する。これにより、端末応答を省略しつつ、システム負荷を減らすことができる。
【００８９】
このように、本実施形態では、「派生トランザクション」に関して次の２通りの用い方を開示する。（１）オンライントランザクションを直接要求された業務とし、このオンライン時に応答する必要はないが、このオンライントランザクションの処理結果に応じて処理しなければならない業務処理を派生トランザクションとして処理する。この（１）は、従来バッチ処理で行っていた処理、又はバッチ処理をオンライン化したことにより必要となる処理を派生トランザクションとして実行することで、オンラインの応答性を確保する。（２）端末とＣＰＵとの通信時間を減少させるために、オンライン応答自体を処理せずに、主体的な業務を派生トランザクションの繰り返しで処理する。この（２）は、端末折り返し連続処理や、承認通知処理などが該当する。
【００９０】
次に、派生トランザクションモデルにて、ＣＰＵの負荷に応じて派生トランザクションの実行を制限する手法を説明する。派生トランザクションは、派生起動トランザクションと同期して実行される必要はない。このため、派生起動トランザクションであるオンライントランザクションのみをコミットし、一方、派生トランザクションの実行については中止することもできる。派生トランザクションの実行を中止すると、ＣＰＵの負荷は軽減され、オンライン処理の応答性を良好に維持することができる。中止された派生トランザクションは、ＣＰＵの負荷が軽減された状態で、再起動すればよい。さらに、センター一括処理など、派生トランザクションが起動される可能性があり、且つ、内部的な処理については、ＣＰＵの負荷が多い場合にその入力を中断するようにしても良い。このように、本実施形態では、付随業務によってオンラインの応答が悪化する事態を最大限防止しつつ、複雑な業務を実行している。
【００９１】
再度図１を参照すると、演算手段４は、前記オンライン応答部１０及び派生トランザクション管理部１２によって実行が管理されるトランザクションの総量に応じて前記派生トランザクションの起動を制限させる総量制御部１４を備えている。派生トランザクションの起動の制限は、例えば、派生起動トランザクションとなる業務処理要求のうち、内部的な業務処理要求についてその入力を待機（中断）させたり、また、業務処理要求を実行しつつ、派生トランザクションの起動を中止したり、さらに、派生起動トランザクションの実行をエラーとする処理などを含む。
【００９２】
この例では、総量制御部１４は、実行を待機しているトランザクションの総数を監視する実行状況監視機能２６と、この実行状況監視機能２６によって実行待機中のトランザクション数が予め定められた第１レベルの数を超えたと判定された場合には派生起動トランザクションとなる業務処理要求の入力を中断させる派生起動取引入力中断制御機能２８とを備える。また、総量制御部１４は、実行状況監視機能２６によって実行待機中のトランザクション数が予め定められた第２レベルの数を超えたと判定された場合には、前記派生起動情報がファイルに登録された状態で派生トランザクションの起動を中止する派生起動中止制御機能３０を備えるようにしてもよい。
【００９３】
図１に示す例では、実行を待機しているトランザクション（業務処理要求の要求メッセージ）の数に基づいて総量制御をする。業務処理要求の数は、例えば待ち行列に格納された要求メッセージの数である。ここでは、派生トランザクションの起動の減少を促す第１のレベルと、直ちに派生起動を中止する第２のレベルとの２段階の制御を行う。派生起動取引入力中断制御機能２８は、待機中のトランザクション数が第１のレベルを超えたときに、例えば先日付完結処理システムでのセンター一括処理を要求する業務処理要求の入力を中断する。派生起動中止制御機能３０は、第２のレベルを超えたときに、実行中の派生起動トランザクションから起動要求される派生トランザクションの実行開始を中止する。これにより、ＣＰＵの負荷が大きくなる状態であっても、オンライントランザクションの応答性の悪化を防止する。
【００９４】
図６は２段階の総量制御を行う総量制御処理の構成を示すフローチャートである。ここでは、第１のレベル＜第２のレベルとする。まず、トランザクションの滞留又は実行状況を調査する（ステップＳ４１）。待ち行列等に格納されたトランザクションの総数が第１のレベルを越えている場合には、派生起動トランザクションの入力を中断させる（ステップＳ４２）。さらに、第２のレベルを越えた滞留がある場合には、現に実行している派生起動トランザクションによる新たな派生トランザクションの起動を中止させる。これは、派生起動情報をファイル６に格納した後、派生起動メッセージを出力しないことで行うと良い。
【００９５】
一方、待ち行列に登録されている業務処理要求が第１レベルよりも少ない場合に（ステップＳ４６）、派生トランザクションに関する中断及び中止の継続中であれば（ステップＳ４７）、滞留数が０であるか否かを確認し、滞留数が０であれば、派生起動トランザクションとなる業務処理要求の入力再開や、派生トランザクションの再実行を制御する（ステップＳ４８）。ステップＳ４８では、再開（再実行）が可能となった旨を端末に表示し、再開（再実行）のコマンド入力を促すようにしても良いし、滞留数が０となったことやその後一定時間が経過したことをトリガとして自動的に再開（再実行）制御を行うようにしても良い。
【００９６】
本実施形態では、派生トランザクションの起動を中止した場合であっても、ファイル６に格納した派生起動情報に基づいて再起動を管理するため、派生トランザクションの再起動が確実で、且つ容易である。このように、本実施形態では、付随業務を派生トランザクションとすることで、派生起動トランザクションであるオンライントランザクションを早期に同期点に至らせることで直接にオンラインの応答性を良好に保ち、さらに、ＣＰＵの処理能力との関係で滞留しているトランザクション数が増加した場合には、内部的な派生起動トランザクションの入力の中断や、派生トランザクションの起動中止を行うことで、間接的にオンライントランザクションの応答性の悪化を防止する。これにより、予測できないような業務処理要求の集中があった場合や、種々の業務集中日であっても、自動的にオンラインの応答性を一定の水準に維持することができる。
【００９７】
上述したように本実施形態によると、派生トランザクションモデルを活用することで、派生起動トランザクションを早期にコミットさせつつ、仮に派生トランザクションがアボートした場合であっても確実に再起動を制御できる安定性を提供できるため、オンライン応答を良好に保ちつつ複雑な処理を実現することができ、さらに、総量制御を行う場合には、ＣＰＵの能力に応じて派生トランザクションの実行数を制限して間接的にオンライントランザクションの応答性を確保することができる。これにより、例えば、従来夜間バッチ処理で行っていたような業務を日中処理に再構築することができる。ほとんどの局面で、派生トランザクションは限りなくオンライン・リアルタイムに近い処理を可能とする。例えば、勘定系システムを例にすると、残不足で未成立の口座処理がある場合に、ＡＴＭでの入金を行ったとする。入金処理が派生起動トランザクションであるため、早期にコミットし、入金による残高を通帳に記帳する。この通帳記帳を行っている間に、派生トランザクションによる未成立の口座処理の再カットが完了する。このため、通帳には再カットされた後の残高を続けて印刷することができる。
【００９８】
このように、派生トランザクションは、通常はほぼオンライン・リアルタイムに近い状態で処理され、一方、例外的に処理が長くなる場合や、ＣＰＵの負荷が大きい場合には数十秒後に処理され、また、付随業務のアプリケーションに問題があってエラーとなった場合であっても、オンラインの応答を完了しつつ、アプリケーションの修正を行い、事後的に付随業務のみを再実行することもできる。このように、派生トランザクションモデルでは、１つのトランザクションで多数の処理を行う場合の弊害からプログラマとシステムとを解放することができ、特に、通常のトランザクションモデルでは実現を断念しがちな複雑な処理のシステム開発が可能となる。
【００９９】
【第２実施形態】
第１実施形態にて開示したように、派生トランザクションモデルはオンラインの応答性と複雑な業務処理の実現との優れた調和をもたらす。しかし、派生トランザクションモデルや、連鎖トランザクションモデルは標準化されていないため、使用するトランザクション管理システム（ＴＰモニタ，トランザクションマネージャ）によっては、その機構は提供されない。しかし、派生トランザクションの特性は、ＤＢに対するロック機構を用いることで確保することができる。第２実施形態では、この派生トランザクションの特性を管理するために２つのデータベースを用いる例を開示する。この第２実施形態を適用することで、通常のトランザクションのＡＣＩＤ特性を管理できる。すなわち、ＤＢのロッキングによる直列性の確保を行うことができるシステムであれば、派生トランザクションモデルを構築することができる。この第２実施形態が２つのデータベースを用いる理由は種々あるが、その一つはこの２つのＤＢの再編成処理を不要とするためである。従って、２つのＤＢを用いるようにしても、システム管理上の負荷が増えることはない。
【０１００】
＜派生トランザクション管理＞
図７は、本実施形態による勘定系システムを構成するトランザクション制御システム（又は、オンラインシステム）の構成の概要を示すブロック図である。トランザクション制御システムは、端末等１Ａ，１Ｂ，…，１Ｇからネットワーク３Ａ，３Ｂを介して入力される業務処理要求を受信する受信手段２と、この受信手段２にて受信した業務処理要求を処理する演算手段４と、この演算手段４による業務処理要求の処理結果を記録するファイル６とを備えている。受信手段２は、図７に示す例では、通信制御装置５２である。
【０１０１】
通信制御装置５２は、内部（行内）ネットワーク３Ａや、対外ネットワーク３Ｂと接続されている。各ネットワーク３Ａ，３Ｂは、物理的、論理的に多数のネットワークを含むようにしても良い。通信制御装置５２は、内部ネットワーク３Ａを介して、顧客とのオンライン取引に用いられるＣＤ／ＡＴＭ１Ａや、営業店内に配置され営業店の担当者によって操作される営業店端末１Ｂや、顧客からの電話による取引を遂行するためのテレフォンバンキングセンタ１Ｃと接続されている。
【０１０２】
また、通信制御装置５２は、対外ネットワーク３Ｂを介して他の金融機関との為替等の通信を制御する全銀センタ１Ｄや、その他の外部センタ１Ｅや、ファームバンキングやインターネットバンキングを行う顧客のパーソナルコンピュータ等の顧客ＰＣ１Ｆや、携帯電話等の顧客携帯端末１Ｇと接続されている。
【０１０３】
各端末１Ａ，１Ｂ，１Ｃ，１Ｆ，１Ｇや、センタ１Ｄ，１Ｅ等から、通信制御装置５２を介してＣＰＵに入金や出金の要求が入力される。また、通信制御装置５２には、センター一括処理の開始を要求するコマンド（業務処理要求）や、アボートされた派生トランザクションの再起動を要求するコマンドを入力するコンソール端末２Ａが接続されている。全銀センタ１Ｄは、全国銀行データ通信システムのセンタである。個人情報センタや、他行コンピュータセンタと接続されている。振込、送金等の為替取引を行う要求指令（電文）が送受信される。
【０１０４】
外部センタ１Ｅは、金融機関の業態別に構築された各種のネットワーク（地方銀行のＡＣＳ，都市銀行のＢＡＮＣＳ，全国キャッシュサービスのＭＩＣＳ等）のセンタや、ファームバンキング（ＦＢ）やエレクトロニックバンキング（ＥＢ）や、テレフォンバンキングに必要なデータの送受信を行うためのセンタ（例えば、ＡＮＳＥＲ）や、販売店のＰＯＳシステムやクレジットカード決済用の端末との通信を行うためのセンタ（例えば、ＣＡＦＩＳやＤＣＳ）である。この外部センタからは、通知、照会、資金移動など、金融機関窓口で可能な種々の取引を行う要求指令（電文）が入力される。
【０１０５】
通信制御装置５２は、それぞれのプロトコルに従って要求指令を受信し、演算手段４を構成するＣＰＵに入力する。ＣＰＵは、各端末からそれぞれの形態で入力される要求指令を予め定められた形式の口座処理要求に変換して、口座処理を行うプログラムに引き渡す。
【０１０６】
また、公共料金の振替等（外部自振）は、持ち込み媒体５４にて持ち込まれる。ＣＰＵは、媒体読取部５６によって読み取られた外部自振原データと他のデータベース（ＤＢ）を用いて業務処理要求を生成する。図７に示す例では、勘定系システムは、持ち込み媒体５４から読み出したデータや、予め登録した自振契約や融資返済等に関するデータを記録する自振関連ＤＢ５０と、この自振関連ＤＢに格納されたデータに基づいて口座振替等の自動振替を行うため業務処理要求群である自振入力ファイルを生成する自振入力ファイル生成手段６０と、この自振入力ファイル生成手段６０によって生成された自振入力ファイルであるセンターカット電文をコンソール端末２Ａのオペレーションに応じてトランザクション管理部６４に入力するセンターカット電文入力手段６２とを備えている。センターカット電文は、センター一括処理を指示する電文であり、自振の処理要求を複数ブロッキングした電文である。自振の処理要求を５つブロッキングした場合、このセンターカット電文によるトランザクションは自動振替を５つ処理する。
【０１０７】
ファイル６は、図７に示す例では、派生トランザクションの派生起動情報を派生管理通番毎に記録する派生管理ＤＢ７０と、この派生管理ＤＢ７０のキーとなる派生管理通番毎に派生管理ＤＢが使用中であるか否かを指示するインデックス情報を記録する派生インデックスＤＢ６８とを備えている。また、ファイル６は、トランザクションの滞留に応じたシステムの状況を示すビット（派生起動取引中断ビット等）などを記録するシステム状況ＤＢ８３を備えている。
本実施形態では、派生管理ＤＢ７０に派生起動情報を格納する。そして、この派生起動情報の振る舞いを利用して、派生トランザクションの特性を管理する。
【０１０８】
派生起動トランザクションは派生起動情報を格納する。しかし、派生起動トランザクションがアボートされた場合には、ロールバックにより派生起動情報の更新がなかったこととされる。従って、派生トランザクションは、起動開始直後にこの派生起動情報の読み込みを行うことで、派生起動トランザクションがコミットしたか又はアボートしたかを知ることができる。例えば、派生起動情報に使用中フラグを含める例では、派生起動トランザクションがコミットすれば、この使用中フラグは「使用中」（例えば、キャラクターの“１”）である。一方、アボートされた場合には、派生起動トランザクションによる使用中フラグの「使用中」への更新があったとしても、その更新はロールバックされる。このため、派生トランザクションは、派生起動情報の使用中フラグが「使用可」（例えば、キャラクターの“０”）である場合には、その派生起動トランザクションがアボートされたと判定することができる。これにより、派生起動トランザクションがコミットした場合にのみ派生トランザクションがコミットするという条件を満たすことができる。
【０１０９】
また、派生トランザクションは、派生起動トランザクションの実行中に起動要求依頼される。従って、派生起動トランザクションのコミット前に、派生トランザクションがスケジュールされ、処理を開始してしまうことがある。これを防止するために、派生トランザクションは、その開始直後に派生起動情報を読みに行く。派生起動トランザクションがコミットするまでは、この派生起動情報はロックされているため、派生トランザクションは、そのロックが解除されるまで待機する。すなわち、派生トランザクションは、その開始時に派生起動情報を読み取ることで、派生起動トランザクションのコミットを待機する。これにより、派生起動トランザクションと派生トランザクションとの直列性を管理する。
【０１１０】
このように、派生起動トランザクションがその一部として派生起動情報を格納し、派生トランザクションが処理の開始時に派生起動情報を読み取ることで、拡張された直列性という派生トランザクションの特性を実現することができる。
【０１１１】
また、派生管理ＤＢ７０のみとして、派生インデックスＤＢ６８を用いないことも可能であるが、派生インデックスＤＢ６８を用いると、派生管理ＤＢ７０の再編成を不要とし、データの削除等のメンテナンスを行うことなく２４時間連続稼働させることができる。派生インデックスＤＢ６８は、派生管理通番の状態（使用中又は使用可）を管理する。トランザクション管理部６４が使用可の派生管理通番を使用するとき、派生トランザクションの正常なコミットによって不要となった派生起動情報を消去し、新たな派生起動情報を記録する。従って、不要となった派生起動情報は次々と上書きされるため、派生管理ＤＢの再編成処理を行う必要がなくなる。この派生起動情報を上書きする例では、派生インデックスＤＢ等を用いて消去しても良い派生起動情報を格納したセグメントを示す派生管理通番を特定する。従って、データを格納しているという点では、派生管理ＤＢは未使用であるとは限らない。データが格納されていても、その派生起動情報は役割を終えて消去可能な状態である。この消去可能な状態を、「使用可」という。
【０１１２】
図７に示す例では、ファイル６はさらに、センター一括処理を要求する電文（業務処理要求群）を生成するための自振関連ＤＢや、取引明細や、融資に関連する情報などを格納する各種のマスタＤＢを備えている。
【０１１３】
演算手段４は、前記端末等から入力される業務処理要求をオンライントランザクションとして処理させると共に当該処理結果を前記端末への応答として出力する制御をするオンライン応答部５８と、前記オンライントランザクション又は所定の派生トランザクションの実行処理の一部として起動要求される派生トランザクションを管理すると共に前記オンライントランザクションを管理するトランザクション管理部６４とを備えている。
【０１１４】
本実施形態では特に、トランザクション管理部６４が、派生インデックスＤＢを参照して使用可の派生管理通番を特定する派生管理通番特定機能１０１と、特定された派生管理通番のセグメントに派生起動情報を格納する派生起動情報格納制御機能１０２と、この派生起動情報の格納後に派生トランザクションをコミットさせる派生起動トランザクションコミット処理機能１０３と、派生起動トランザクションがアボートした場合には派生トランザクションの処理を開始させずに終了させる直列性制御機能１０４と、派生トランザクションをコミットさせると共に使用した派生管理通番等を使用可に更新する派生トランザクションコミット処理機能１０５とを備えている。また、トランザクション管理部６４は、アボートされた派生トランザクションの再起動を制御する派生再起動制御機能１０６とを備えている。
【０１１５】
派生管理通番特定機能１０１は、オンライントランザクション又は派生トランザクションである派生起動トランザクションから派生トランザクションの起動要求依頼があったときに、前記派生インデックスＤＢ６８のインデックス情報を特定すると共に、当該特定したインデックス情報に基づいて前記派生管理ＤＢの使用可の派生管理通番を特定する。並列に実行されている全てのトランザクションが一つのインデックス情報を読み取る仕組みとすると、このインデックス情報へのコンテンションが増大してしまう。このため、本実施形態では、派生管理通番特定機能１０１は、なんらかの条件に従って起動要求依頼を発行した派生起動トランザクションが利用できるインデックス情報を特定する。インデックス情報を特定できると、そのインデックス情報を参照して使用可の派生管理通番を特定する。派生管理ＤＢへのアクセスは、派生管理通番をキーとして行うため、意図しないコンテンションは発生しない。
【０１１６】
派生起動情報格納制御機能１０２は、派生管理通番特定機能１０１によって特定された派生管理通番のセグメントに前記派生起動トランザクションによる派生トランザクションの起動要求依頼に関する派生起動情報を格納する。派生起動情報格納制御機能１０２は、この派生起動情報の格納後に、派生トランザクションを起動する。
【０１１７】
派生起動トランザクションコミット処理機能１０３は、派生起動情報を与えられた派生管理通番のセグメントに格納した後で、当該派生起動トランザクションの各処理が正常終了した場合に、当該派生起動トランザクションをコミットさせる。第１実施形態と同様に、派生起動トランザクションは派生トランザクションの運命に関わらず早期に同期点に達する。そして、直列性制御機能１０４は、派生トランザクションの開始時に前記派生起動情報をロック可能な状態での正常な読み出しに成功した場合に当該派生トランザクションの各処理を開始させる。「正常な読み出し」は、派生起動トランザクションによって格納された状態での読み出しを意味する。すなわち、直列性制御機能１０４は、派生起動トランザクションがアボートされ、この派生起動トランザクションによって格納された派生起動情報がロールバックにより無かったものとされている場合には、正常な読み出しができなかったとして、派生トランザクションの起動を行わない。
【０１１８】
派生トランザクションコミット処理機能１０５は、派生トランザクションの各処理が正常終了した場合に、使用した派生管理通番について前記派生インデックスＤＢ６８及び前記派生管理ＤＢ７０を使用可に更新させる。この派生インデックスＤＢ及び派生管理ＤＢを使用可に更新する処理と前後して、当該派生トランザクションをコミットさせる。派生インデックスＤＢを使用可に更新する処理は、派生トランザクションの一部として実行しても良いし、また、第３実施形態で詳述するように別のトランザクション（派生ＤＢ制御処理）にて行うようにしても良い。
【０１１９】
派生再起動制御機能１０６は、派生トランザクションがアボートされた場合に、派生管理ＤＢに格納した派生起動情報に基づいた再起動を制御する。再起動は、自動的に行うようにしても良いし、再起動を指示する業務処理要求を受信したときに実行するようにしても良い。
【０１２０】
図８は、ＪＯＢと派生インデックスＤＢ等との関係を示す説明図である。ＴＰモニタの一種であるＣＩＣＳやＩＭＳでは、リージョン（region）と呼ばれる抽象化を提供している。リージョンは、複数の処理を実行できるアドレス空間である。リージョンは資源を保有する単位であり、アプリケーション実行時の障害はリージョン内に局所化される。業務処理要求は、リージョンにスケジュールされる。例えばリージョンを５０個起動する場合には、ＪＯＢ番号０から４９までのトランザクションが並行して動作する。ＪＯＢ番号は、予め固定された番号とする。このように、リージョン数が予め定められており、且つ、使用するＪＯＢ番号（例えば、ＪＯＢ名の下三桁の数値）が予め定められた範囲内の数値である場合には、派生インデックスＤＢ６８のインデックス情報をＪＯＢ番号を単位として構築すると良い。この場合、別のリージョンで並行して実行されているトランザクションとインデックス情報の読み取りで競合することがない。リージョンの概念を用いないシステムであっても、並列して実行されるトランザクションを識別するための番号は必ず存在する。この場合、ＪＯＢ番号としてトランザクションＩＤ又はこれを編集した番号を用いる。ＪＯＢ番号は、並列して実行されるトランザクション又はプロセス間でユニークで、且つ、その番号が予め定められた範囲内の数値であれば良い。
【０１２１】
図８に示す例では、派生起動トランザクションは、予め定められたＪＯＢ番号群の中のいずれかのＪＯＢ番号で実行される。そして、派生インデックスＤＢが、前記トランザクションのＪＯＢ番号をキー値となるインデックス領域番号８８として当該インデックス領域番号８８毎にインデックスビットマップ６８を有する。そして、図８に示す例では、派生インデックスＤＢは、前記インデックス情報を前記インデックス領域番号毎のビットマップとして保有している。リージョン０では、ＪＯＢＦＰ０００がスケジュールされ、実行している。ＪＯＢＦＰ０００のトランザクションがインデックス情報（ビットマップ）を読み取る場合には、このＪＯＢ名の下三桁の数値である「０００」をキー値として派生インデックスＤＢにアクセスする。すると、インデックス領域番号が「０００」であるビットマップにアクセスする。このビットマップでは、先頭から「１１１００…」となっている。同様に、リージョン１で動作するトランザクションはインデックス領域番号が「００１」のビットマップにアクセスする。このビットマップは、先頭から「０１００…」となっている。
【０１２２】
インデックス情報をビットマップとする例では、ビットのＯＮ（１），ＯＦＦ（０）で派生管理通番が使用中であるか否かを示し、そのビットの位置で派生管理通番を特定する。ここでは、一例として、１つのリージョンから利用できる派生管理通番を４００個とする。この場合、ビットマップは、４００ビットある。すなわち、１バイトを単位とする場合には長さが５０となる。リージョン０を例とすると、派生管理通番０００１，０００２，０００３は使用中で、それ以降が使用可である。この３つの派生管理通番が使用中であるということは、リージョン０から起動要求された３つの派生トランザクションがそれぞれコミットしていないことを意味する。
【０１２３】
派生管理通番特定機能１０１は、例えば、ビットマップを順に先頭から読み出し、「０」であるビットのビット位置を特定する。そして、このビット位置から派生管理通番を求める。例えば、リージョン０の場合、先頭から４番目のビットが「０」であるため、特定する派生管理通番は０００４となる。リージョン１の場合、派生管理通番は０４０１から開始するため、ビットマップの先頭を特定した場合には、派生管理通番は０４０１となる。
【０１２４】
このように、好ましい実施形態では、派生管理通番特定機能１０１が、前記インデックス領域番号８８と前記ビットマップのビット位置とに基づいて前記派生管理ＤＢ７０の派生管理通番を特定する機能を備える。
【０１２５】
図９は、この場合の派生ＤＢのデータ項目を例示する説明図であり、図９（Ａ）は派生インデックスＤＢの項目例を示す図である。Ｎは例えば１２５、Ｍは４００とする。派生インデックスＤＢ６８は、その項目として、インデックス領域番号（各ビットマップに付されＪＯＢ番号と同一の数値）と、ビットマップ（インデックス・ビットマップ）とを備えている。また、派生インデックスＤＢは、そのビットマップが特定する派生管理通番の残り個数と派生件数とを格納する。例えば、残り個数が０であれば派生トランザクションの起動を待機する等の処理を行う。図９（Ａ）の残り個数の初期値Ｍは、上記の例では４００である。
【０１２６】
図９（Ｂ）は派生管理ＤＢの項目例を示す図である。派生管理ＤＢは、キー値として派生管理通番を有する。その他の項目は派生起動情報の詳細である。派生起動トランザクションのＡＰＰＬ ＩＤと、派生トランザクションのＡＰＰＬ ＩＤとを保持することで、どの主業務がどの付随業務を派生起動したのかを記録する。派生編集番号は、入出力の形式を特定するために利用する。エントリー日付及び時刻は、アボートされた派生トランザクションの探索に利用する。使用中フラグは、派生トランザクションが派生起動トランザクションがコミットされたか否かを知るために用いる。ＦＩＦＯ保存とあるのは、派生起動トランザクションが派生トランザクションを起動するために用意した各種のデータ内容の保存領域である。
【０１２７】
本明細書では、ＦＩＦＯというときには、定型入出力情報域（Formatted Input Formatted Output）を意味する。先入れ先出し方式の略語としては用いない。ＦＩＦＯは、ＩＭＳ／ＥＳＡオンライン適用業務開発／運用支援プログラムであるＳＡＩＬによって提供される抽象化である。端末等からの全ての入力は、その業務に応じてＦＩＦＯという情報域に編集され、セットされる。このため、適用業務プログラムは、端末等から入力の形式によらず、予め定義したＦＩＦＯでの位置に特定の項目のデータがセットされている前提で開発することができる。すなわち、ＦＩＦＯを用いることで、入出力メッセージの形式によらず、適用業務プログラムを開発することができる。入出力メッセージとＦＩＦＯとは、編集定義を用いて関連させる。例えば、派生起動トランザクションが派生トランザクションを起動する場合には、派生トランザクションの実行に必要なデータをＦＩＦＯにセットし、派生起動要求依頼を行う。すると、ＳＡＩＬは、派生編集番号に従ってＦＩＦＯから派生メッセージを生成する。端末からの業務処理要求の入力や、端末への出力メッセージについても同様に業務毎の編集定義を用いる。
【０１２８】
図１０は、ＪＯＢ番号と、派生インデックスＤＢ６８のインデックス領域番号８８と、ビット位置と、符号８９で示す派生管理通番との関係を例示する説明図である。図１０（Ａ）に示すように、ＪＯＢ番号０００で実行されているトランザクションによって読み出されるインデックス・ビットマップの番号（インデックス領域番号）は、「０００」である。図１０（Ａ）に示す例では、ビット位置１及び５が使用中である。この場合、派生管理ＤＢの内容は図１０（Ｂ）に示す如くとなる。派生起動トランザクション側では、インデックス・ビットマップのビット（派生インデックスビットと呼ぶ）と、使用中フラグとは、原子性に包まれていることが望ましい。
【０１２９】
図１０（Ｃ）及び（Ｄ）に示すように、１つのインデックス・ビットマップが特定する派生管理通番の数Ｍが定められていると、インデックス領域番号８８とビット位置とに基づいて派生管理通番を特定することができる。
【０１３０】
図１１は、派生トランザクションの要求を管理するための派生要求管理処理の一例を示すフローチャートである。図１２は、派生トランザクションの特性を管理するための派生特性管理処理の一例を示すフローチャートである。図１１に示す派生要求共通処理は、派生起動トランザクションの一部として実行される。図１２に示す派生特性管理共通処理は、派生トランザクションの一部として、または別の処理として実行する。
【０１３１】
図１１を参照すると、派生要求共通処理は、派生起動トランザクションから派生起動要求依頼を受けると、まず、そのＪＯＢ番号（すなわち、インデックス領域番号）をキー値として派生インデックスＤＢを読み込む（ステップＳ５２）。そして、インデックス領域番号での残り個数フィールドをチェックし（ステップＳ５２）、空きがあれば、インデックス・ビットマップから空き（インデックスビットが０）のビット位置を特定する。ステップＳ５２にて空きが無い場合には、予備の派生インデックスＤＢを読み込み、残り個数フィールドをチェックする（ステップＳ６２）。予備の派生管理通番まで使用中である場合には、異常終了する。
【０１３２】
空きの派生インデックスビットを特定すると、そのビット位置に基づいて派生管理通番を算出する。そして、この派生管理通番を派生起動トランザクションが動作しているリージョンのＦＩＦＯにセットする。さらに、派生インデックスビットをＯＮ（対応する派生管理通番が使用中）を示す「１」に更新する（ステップＳ５４）。
【０１３３】
続いて、派生管理通番をキー値として、派生管理ＤＢを読み込み（ステップＳ５５）、派生インデックスＤＢ６８の残り個数フィールドと、派生件数フィールドとを更新する（ステップＳ５６）。そして、派生管理ＤＢに派生起動情報を登録し、派生管理ＤＢ７０の使用中フラグを「使用中」とする（ステップＳ５７）。続いて、派生トランザクションの起動を制御する（ステップＳ５８）。例えば、ＳＡＩＬは、派生起動トランザクションのＦＩＦＯから派生メッセージを生成し、待ち行列に登録する。続いて、派生起動トランザクションはコミットする。
【０１３４】
図１２は、派生トランザクションの開始及び終了時等の処理を示すフローチャートである。派生特性管理共通処理では、まず、派生トランザクションがいずれかのリージョンにスケジュールされると、まず、派生起動メッセージの派生管理通番をキー値として派生管理ＤＢ７０を読み込む。派生起動トランザクションがコミットしていない段階では、派生管理ＤＢ７０の当該派生管理通番のセグメントはロックされているため、ステップＳ７１では、派生起動トランザクションがコミット又はアボートし、このロックが解除されるまで待機する。
【０１３５】
派生トランザクションは、派生管理ＤＢの内容の読み出しに成功すると、まず、使用中フラグをチェックする。使用中フラグは、派生起動トランザクションによってステップＳ５７によって使用中を示す１に更新にされている。派生起動トランザクションがコミットした場合、この使用中フラグは「使用中」のままである。一方、派生起動トランザクションがステップＳ５８以後にアボートした場合、ロールバックによって、派生起動トランザクションによる使用中フラグの「使用中」への更新が取り消され、使用中フラグは使用可を示す０となっている。従って、ステップＳ７２では、使用中フラグが使用可の場合には、派生起動トランザクションがコミットした場合にのみ派生トランザクションがコミットするという派生トランザクションの性質に従って、派生トランザクションの適用業務プログラムを実行せずに終了する（ステップＳ７４）。
【０１３６】
派生起動トランザクションが正常にコミットしている場合、使用中フラグは「使用中」であるため、派生トランザクションの適用業務プログラムを呼び出し、実行を制御する（ステップＳ７５）。この適用業務プログラムの実行が完了すると、派生特性管理共通処理では、派生管理通番をキーとして派生管理ＤＢを読み込む（ステップＳ７６）。そして、使用中フラグを使用可に更新する（ステップＳ７７）。このとき、派生インデックスＤＢの派生インデックスビットも使用中のままとなっている。このため、派生トランザクションの一部として、又は別のトランザクションを用いて、派生インデックスＤＢ７８の派生インデックスビットをオフに更新する。この派生インデックスビットの更新に前後して、派生トランザクションはコミットする。
【０１３７】
また、図１２に示す派生特性管理共通処理によってその特性が管理される派生トランザクションが、別の派生トランザクションを起動する場合には、この派生トランザクションをコミットさせる前に、図１１に示す処理を実行する。
【０１３８】
ここで、図７に示す各機能と、図１１及び図１２に示す各工程との関係を説明する。図７に示すトランザクション管理システムの各機能１０１，１０２，１０３，１０４，１０５，１０６は、第１実施形態の場合と同様に、ＣＰＵが、派生管理通番特定機能１０１を実現するための派生管理通番特定指令や、派生起動情報格納制御指令などを実行することで実現できる。
【０１３９】
例えば、このプログラムは、オンライントランザクション又は派生トランザクションである派生起動トランザクションから派生トランザクションの起動要求依頼があったときに前記派生インデックスＤＢのインデックス情報を特定させると共に当該特定したインデックス情報に基づいて前記派生管理ＤＢの使用可の派生管理通番を特定させる派生管理通番特定指令を備えている。この指令を実行すると、ＣＰＵは派生管理通番特定機能１０１として動作する。図１１に示す例では、この派生管理通番特定指令を実行すると、ＣＰＵはステップＳ５１，５２，Ｓ５３及びＳ５４等の工程を実現する。
【０１４０】
また、このプログラムは、派生管理通番特定指令に応じて特定された派生管理通番のセグメントに前記派生起動トランザクションによる派生トランザクションの起動要求依頼に関する派生起動情報を格納させると共に当該派生起動情報を格納した後に当該派生トランザクションを起動させる派生起動情報格納制御指令を備える。ＣＰＵは、この指令を実行することで派生起動情報格納機能１０２として動作する。図１１に示す例では、ステップＳ５４，Ｓ５５，Ｓ５６，Ｓ５７の工程を処理する。
【０１４１】
プログラムは、さらに、派生起動情報の格納後で当該派生起動トランザクションの各処理が正常終了した場合に当該派生起動トランザクションをコミットさせる派生起動トランザクションコミット処理指令を備える。これにより、ＣＰＵは、派生起動トランザクションコミット処理機能１０３として動作する。ステップＳ１１では、最後の工程である。
【０１４２】
また、プログラムは、前記派生トランザクションの開始時に前記派生起動情報をロック可能な状態での正常な読み出しに成功した場合に当該派生トランザクションの各処理を開始させる直列性制御指令を備える。図１２に示す例では、これは、ステップＳ１２の派生起動情報の読み取り工程Ｓ７１によって、この直列性の制御を実現する。直列性制御指令を実行するＣＰＵは、直列性制御機能１０４として、図１２に示すステップＳ７１からＳ７５の処理を行う。
【０１４３】
派生トランザクション管理用プログラムはさらに、派生トランザクションの各処理が正常終了した場合に使用した派生管理通番について前記派生インデックスＤＢ及び前記派生管理ＤＢを使用可に更新させると共に当該派生トランザクションをコミットさせる派生トランザクションコミット処理指令を備える。この指令を実行するＣＰＵは、派生トランザクションコミット処理機能１０５として、図１２に示すＳ７６，Ｓ７７，Ｓ７８，Ｓ７９の処理を行う。第３実施形態では、デッドロックの発生を防止するために、派生トランザクションとは別のトランザクションとしてＳ７８及びＳ７９による派生インデックスＤＢの更新を行う。
【０１４４】
また、このプログラムは、派生トランザクションがアボートされた場合には前記派生管理ＤＢに格納した派生起動情報に基づいた再起動を制御する派生再起動制御指令を備える。この派生再起動制御指令を実行するＣＰＵは、派生再起動制御機能１０６として機能する。実際の再起動処理は、派生再起動制御部７７が行うようにしても良い。このように、図７に示す各部や図１１，図１２等のフローチャートに示す各工程は、それぞれの処理を行うプログラムを実行することによって実現できる。これは、総量制御処理や（図１９）、派生再起動要否判定処理（図２２）や、派生再起動制御処理（図２３）の各フローチャートに示す工程についても同様である。
【０１４５】
このように、図１１及び図１２に示す例では、派生インデックスＤＢ６８が、前記インデックス領域番号８８毎のビットマップを派生インデックスビットの列として有すると共に、当該派生インデックスビットのＯＮ又はＯＦＦに応じて当該ビットのビット位置に対応する派生管理ＤＢ７０の使用状態を記録している。そして、派生管理ＤＢ７０は、派生管理通番毎に当該派生管理通番の使用状態を使用中又は使用可として記録する使用中フラグを有する。
【０１４６】
さらに、派生管理通番特定機能１０１は、使用可を示すＯＦＦ（０）の派生インデックスビット及び使用可（０）の派生管理通番を特定したときに、当該派生インデックスビットについて使用中を示すＯＮ（１）へと更新する（ステップＳ５４）。続いて、派生起動情報格納制御機能１０２は、派生起動情報を格納したときに当該派生管理通番の使用中フラグについて使用中（１）へと更新する（ステップＳ５７）。そして、直列性制御機能１０４は、前記派生起動トランザクションから渡された派生管理通番の使用中フラグが使用可（０）であった場合には当該起動要求されている派生トランザクションを起動せずに処理を終了させ（ステップＳ７４）、派生トランザクションコミット制御機能１０５は、当該派生トランザクションの完了時又は完了後に前記派生インデックスビット及び前記使用中フラグについて使用可の状態（０）へと更新する（ステップＳ７７，Ｓ７９）。すなわち、派生インデックスビットをＯＦＦ（０）とし、使用中フラグを使用可（０）とする。
【０１４７】
このように、派生起動トランザクションと派生トランザクション間の派生起動情報のコンテンションを利用することで、派生トランザクションの性質を一般的なＤＢのロック機構を用いて実現することができる。
【０１４８】
次に、先日付完結処理システムでの取消再カットメインを例として派生トランザクション管理の一例を説明する。
トランザクションのコミットのタイミングをプログラム中に記述しない方が、そのプログラムの再利用性は高まる。このため、トランザクションの実行を管理するプログラムが、適用業務プログラム（ＡＰＰＬ）を呼び出し、実行し、正常に終了した段階でコミットを与える仕組みとすると、ＡＰＰＬを種々の態様で利用することができる。トランザクションの管理を行うプログラムを、ここでは業務メインと呼ぶ。また、ＡＰＰＬの実行形態として、端末から初回に入力された場合や、連続して繰り返し処理する場合や、連動処理として呼び出された場合や、派生トランザクションとして起動された場合や、センター一括処理として入力される場合などがある。これらの取引の態様が異なっても、プログラムの一部または全体が共通する場合がある。このため、プログラムを細分化しておき、起動の形態に応じて適切なプログラムを特定する仕組みとすると、プログラムの再利用性が高まり、全体の行数を少なくすることができる。
【０１４９】
図１３は、このような仕組みを提供するためのオペコードテーブルの一例を示す説明図である。業務処理要求や、派生トランザクションの内容は、オペコードで特定される。例えば、普通預金の出金処理のオペコードは０１００１である。そして、端末初回入力の場合には、プログラム０１，０２，０３をこの順に呼び出して実行する。同様に、連動処理の依頼を受けた場合には、プログラム０６，０７，０８をこの順に実行する。ＳＡＩＬは、業務処理要求（オペコードを含む）を受信すると、その業務に応じた編集定義を特定し、編集定義に基づいてＦＩＦＯを組み立てると共に、業務メインを呼び出す。業務メインは、オペコードテーブルのプログラムリストに従ってプログラム（ＡＰＰＬ）を呼び出す。
【０１５０】
さらに、業務メインは、派生トランザクションの起動要求依頼を受けた場合には、図１１に示す処理を実行するプログラムを呼び出す。一方、派生トランザクションの起動に際しては、派生トランザクションのオペコードによるＡＰＰＬの呼び出しの前後に、図１２に示す処理を実行する。
【０１５１】
図１３に示すように、普通預金出金のオペコードは、０１００１である。先日付完結処理システムでは、この普通預金出金は取り消されることがある。この取消については、すべてのオペコードについて一定値（図１３に示す例では、５００）を加算する体系としている。これにより、ある取引を取り消す場合にオペコードを探索する必要がなくなる。図１３に示すように、普通預金の出金は、定積入金（０３００１）や、定期入金（０４００１）から連動起動又は派生起動なされる。
【０１５２】
図１４は、取消再カットメインでの処理例を示す説明図であり、図１４（Ａ）は口座処理による電気料引落（内部自振）の取消を行う例を示す図で、図１４（Ｂ）はその処理による残高の推移を示す図である。図１４（Ｂ）に示すように、６日の残高が６０，０００で、７日を勘定日とした電気料の引落（自振通番１２３４５）２０，０００が先日付完結処理により実行され、７日の残高が４０，０００となっているとする。この状態で、ＡＴＭを用いて普通預金から定期預金への入金があると、定期入金処理Ｓ２１は、オペコード０１００１の普通預金出金Ｓ２２を連動起動する。普通預金出金では、６日の残高は６０，０００であるため、５０，０００の出金が可能であることから、５０，０００の出金を行い、成立した旨を定期入金に伝える（連動戻り）。
【０１５３】
定期入金では定期預金マスタ等に記録し、ＡＴＭに定期入金が完了した旨の応答を出力する。一方、普通預金出金Ｓ２２では、６日の残高の更新後に、先日付の勘定日である７日の残高も更新する。７日の残高は、マイナス１０，０００となる。普通預金出金Ｓ２２は、７日の残高がマイナスとなったことから、７日を勘定日として取消再カットメインを起動する。取消再カットメインは、出金可能額のマイナスが解消するまで７日にて成立している口座処理を取り消す制御をする。ここでは、電気料の引落を取り消しを起動する。ステップＳ２４では、電気料の引落の取消（オペコード０２００１＋５００＝０２５０１）を行い、普通出金の取消に連動する。普通出金の取消（オペコード０１００１＋５００＝０１５０１）は、２０，０００の出金の取消を行うため、７日の残高に２０，０００を加算する。そして、７日の口座残高に異動が生じたため、再度取消再カットメインを派生トランザクションとして起動する。取消再カットメインＳ２６は、図４に示す処理を行い、取消再カットの必要性がないことから、なんら起動せずに処理を終了する。
【０１５４】
図１４（Ａ）に示すように、定期入金と普通出金は連動しており、１つのトランザクションＴ１である。これが、リージョン０にスケジュールされ、ＪＯＢ番号が「０００」であるとする。普通出金が派生トランザクションの起動要求依頼をしたとき、トランザクションＴ１はコミットしていない。高速パス（ＦＰ）を用いたシステムでは、トランザクションＴ１のコミットの前に派生トランザクションがスケジュールされる。リージョン０は派生起動トランザクションＴ１によって使用されているため、派生トランザクションである取消再カットメインは、例えばリージョン１にスケジュールされる。この場合、取消再カットメインのＪＯＢ番号は「００１」となる。取消再カットメインＳ２３は、種々の判定処理を行った後に電気料引落の取消を派生トランザクションとして起動する。
【０１５５】
取消再カットメインＳ２３が派生起動トランザクションＴ２として電気料引落の取消処理を起動させたとき、定期入金及び普通出金のトランザクションＴ１は既にコミットしている可能性が高い。すなわち、派生起動トランザクションＴ１はその付随業務である取消再カットメインである派生トランザクションＴ２のコミットを待機せずにコミットする。トランザクションＴ１がコミットしていると、リージョン０は空いているため、電気料引落の取消を行う派生トランザクションＴ３は、リージョン０にスケジュールされることがある。
【０１５６】
図１５乃至図１７は、この状態での派生起動情報の格納及び派生メッセージの出力や、ＦＩＦＯの推移を説明するための説明図である。この例では、ＩＢＭ社のＭＶＳで動作するＩＭＳをＦＰで高速化し、さらにＳＡＩＬによるＦＩＦＯ及び編集定義を使用し、そして、業務メインによりオペコードテーブルを用いて各トランザクションを管理する。この例では、第２実施形態で説明している派生インデックスＤＢ及び派生管理ＤＢを用いている。
【０１５７】
業務メインは、ＡＴＭから定期入金の業務処理要求を、図１５の符号Ｍ１で示す入力メッセージの形式で受信する。入力メッセージＭ１中、Ｈはヘッダー、オペコードは定期入金を示す０４００１（図１３参照）、金額は５０，０００であり、ここでは、普通預金の店番２１１の口座２１ｙｙｙｙから出金して、２１０店番の口座３０００ｘｘｘｘｘに入金する処理を要求する。ＩＭＳは、入力メッセージＭ１を待ち行列から取り出すと、空いているリージョン０へスケジュールし、トランザクションを開始させる。ＳＡＩＬ及び業務メインは、図１７に示すように、このリージョン０内に、入力メッセージＭ１から所定の入力編集定義を用いて定期入金のＦＩＦＯ８６Ａを展開する。図１５に示すように、ＦＩＦＯ８６Ａには、予め定められた位置に、オペコードや、定期入金する店番や、入金金額等が格納される。そして、業務メインは、定期入金のオペコードテーブルを参照して所定のプログラムを呼び出し、実行させる。定期入金プログラムは、普通預金からの出金を依頼するために、オペコード０１００１への連動を起動する。このとき、連動編集定義に基づいて、普通出金用のＦＩＦＯ８６Ｂがセットされる。結果コードは、普通預金からの出金に成功するか否かを示すコードである。
【０１５８】
普通預金出金は、ＦＩＦＯにセットされた２００１／３／６を勘定日とする残高を参照し、出金が可能であるか否かを判定し、出金が可能であれば、６日の残高を１０，０００に更新する。そして、先日付の勘定日が存在するため、７日の残高も更新する。７日の残高がマイナスとなったため、取消再カットメインを処理する開始日（派生日付）を２００１／３／７にセットして、派生起動要求依頼を業務メインに渡す。例えば、派生起動のマクロを実行する。ＳＡＩＬは、普通出金ＦＩＦＯの内容から派生編集定義を用いて派生メッセージ（取消再カットメイン）Ｍ２を生成する。このとき、業務メインは、図１１に示す処理を呼び出す。図１１に示すように、呼び出された派生要求共通処理は、普通出金ＦＩＦＯの内容を派生管理ＤＢに格納する。この例では、ＪＯＢ番号が「０００」であるため、図１７に示すようにインデックス領域１のインデックス・ビットマップを読み取り先頭が「０」であったことから、派生管理通番を１とする。そして、このエントリー日付や時刻等と共に、図１５に示す普通出金ＦＩＦＯ８６Ｂの内容を派生管理ＤＢ７０の派生管理通番１のセグメントに記録する。普通出金ＦＩＦＯが記録された状態では、図１７に示すように、インデックス・ビットマップの先頭の派生インデックスビットがＯＮ（１）であり、また、派生管理通番１の使用中フラグが使用中（１）となる。
【０１５９】
図１５に示すように、普通預金の出金に成功すると、連動戻り編集定義を用いて、連動戻りブロックに出金に成功した旨を示す結果コード（００００）を記録する。定期入金処理は、定期入金に成功したため、定期入金ＦＩＦＯから出力編集定義を用いて出力メッセージを生成し、ＡＴＭに送信させる。これにより、ＪＯＢＦＰ０００のトランザクションＴ１はコミットする。
【０１６０】
ＩＭＳは、派生メッセージＭ２をリージョン１にスケジュールし、ＳＡＩＬは、派生メッセージから取消再カットＦＩＦＯ８６Ｄをセットする。取消再カットメインは、派生トランザクションであるため、業務メインは、まず図１２に示す処理を行う。すなわち、派生特性管理共通処理として、派生管理通番をキー値とした派生管理ＤＢの読み込みを行う。ここでは、派生管理通番１のセグメントを読み取る。すなわち、派生管理ＤＢ７０に格納された普通出金ＦＩＦＯ８６Ｂを読み出す。これにより、トランザクションＴ１のコミットを待機すると共に、Ｔ１のアボートの有無の確認を行う。普通出金を含むトランザクションＴ１が正常にコミットした後、ステップＳ７５に示すように、適用業務プログラムを呼び出す。ここでは、派生メッセージのオペコードである０５００１（取消再カットメイン）を構成するプログラムを呼び出す。取消再カットメインは、取消の対象を特定し、その自振通番（１２３４５６）や、取消金額等を取消再カットＦＩＦＯ８６Ｄにセットし、派生起動要求依頼を行う。業務メインは、図１１に示す派生要求共通処理を実行させる。このとき、取消再カットメインはＪＯＢ番号００１で動作しているため、図１７に示すように、派生管理通番は４０１となる。このため、ＦＩＦＯ８６Ｄの派生管理通番の項目を１から４０１へと更新し、このＦＩＦＯ８６Ｄを派生管理通番４０１のセグメントに格納する。そして、派生編集定義に従って、図１６に示す派生メッセージＭ３を生成する。
【０１６１】
派生メッセージＭ３は自振（電気料引落）の取消であり、オペコードは０２５０１である。トランザクションＴ３は連動取引を用いてこの自振取消を行い、連動受動業務である普通出金取消処理は派生メッセージＭ４を出力させる。このとき、トランザクションＴ３がリージョン０にスケジュールされたとする。
【０１６２】
図１７に示す例では、トランザクションＴ２の派生要求共通処理が派生メッセージを出力させた時点では、トランザクションＴ１がコミットしている。これは、派生起動トランザクションＴ１は派生トランザクションＴ２のコミットを待機せずに早期にコミットすることで、ここでは定期入金処理の応答性を確保していることによる。一方、派生メッセージ（自振取消）Ｍ３は、トランザクションＴ２がコミットする前にスケジュールされる。このため、自振取消を主業務とするトランザクションＴ３はリージョン０にスケジュールされた。トランザクションＴ３では、まず、取消再カットメインであるトランザクションＴ２のコミットを待機するために、派生管理通番４０１の派生管理情報を読み出そうとする。
【０１６３】
トランザクションＴ２がコミットすると、図１２に示すように、業務メインは、派生特性管理共通処理（Ｓ７６，Ｓ７７）をトランザクションＴ２の一部として実行する。さらに、Ｓ７８及びＳ７９もトランザクションＴ２の一部として実行する例では、インデックス領域１の先頭の派生インデックスビットがＯＦＦに更新された後に、派生トランザクションＴ２がコミットする。この場合、トランザクションＴ３が派生トランザクションを起動する時には、すでに派生管理通番１が空いている。
【０１６４】
図１７に示す例では、派生インデックスＤＢのＯＦＦ（対応する派生管理通番が使用可）への更新を別トランザクションとして起動する。この場合、ステップＳ７７が終了した段階でトランザクションＴ２はコミットする。このとき、トランザクションＴ３は派生管理通番４０１の読み出しに成功し、さらに普通預金出金取消が完了すると、再度取消再カットメインを起動しようとする。このとき、トランザクションＴ２によって起動された派生インデックスビットのＯＦＦへの更新処理（派生ＤＢ制御処理）が完了していないと、インデックス領域１の先頭の派生インデックスビットは１のままである。このため、次に空いているビット位置が２の派生インデックスビットを特定する。トランザクションＴ３からの派生起動情報は、普通出金取消ＦＩＦＯ等であり、これが派生管理通番２のセグメントに格納される。
【０１６５】
トランザクションＴ２によって起動された派生ＤＢ制御処理が当該インデックスビットを更新すると、インデックス領域１のインデックスビットの先頭ビットは０となる。このため、次にリージョン０で実行されるトランザクションが派生トランザクションを起動する場合には、派生管理通番１が利用される。このように派生管理通番を繰り返し利用するため、本実施形態では、派生管理ＤＢ及び派生インデックスＤＢの再編成処理が不要である。
【０１６６】
図１５乃至図１７に示す例では、各リージョンは、一般トランザクションと派生トランザクションの双方を実行するものとして説明したが、図１８に示すように、ＪＯＢ番号（リージョン）を一般トランザクションと派生トランザクションとに別々に割り当てるようにしても良い。図１８に示す例では、全てのＪＯＢが派生トランザクションによって使用されるという可能性がなくなるため、オンラインの応答性の悪化を防止することができる。そして、業務処理要求（メッセージ）の取り扱いを容易にするために、図１８に示す例では、オンラインシステムが、待ち行列１３として、オンライントランザクションやセンター一括処理の実行を要求するメッセージ（電文）を一時的に記憶する一般待ち行列１３Ａと、派生トランザクションの実行を要求する派生メッセージを一時的に記憶する派生待ち行列とを備えている。２種類の待ち行列を併用することで、トランザクションの総量制御が容易となる。
【０１６７】
＜総量制御＞
再度図７を参照すると、オンラインシステム（または、トランザクション制御システム）は、図１８に示す一般待ち行列１３Ａ及び派生待ち行列１３Ｂで滞留しているトランザクション数を監視する滞留監視部７８と、この滞留監視部７８によって監視される各待ち行列でのトランザクションの滞留数に応じて前記派生起動トランザクション又は前記派生トランザクションの起動を制御する総量制御部７９とを備えている。
【０１６８】
図１９は、滞留監視処理の一例を示すフローチャートである。滞留監視部７８は、前記一般待ち行列又は派生待ち行列の滞留数が予め定められた第１レベル以上である場合には（ステップＳ８１，Ｓ８３）、派生起動取引中断ビットをＯＮとする（ステップＳ８２，Ｓ８４）。図１９に示す例では、それぞれの待ち行列１３Ａ，１３Ｂに格納されたメッセージ数が２００を越えた場合に、派生起動取引中断ビットをＯＮとしている。そして、前記派生待ち行列に滞留しているトランザクション数が前記第１レベル（２００）よりも多い数にて予め設定された第２レベル（５００）以上である場合には（ステップＳ８５）、派生中止ビットをＯＮとする（ステップＳ８６）。一方、上記各ビットがＯＮとなった後に、それぞれの待ち行列の滞留数が０となった場合には（ステップＳ８７）、各ビットをＯＦＦとする（ステップＳ８８）。この滞留監視部７８による監視処理は、所定の監視時間間隔で、例えば３０秒ごとに繰り返し実行する。滞留監視部７８は、派生起動取引中断ビットや、派生中止ビットを図７に示すシステム状況ＤＢ８３に格納する。
【０１６９】
図２０は、派生トランザクションの実行を待機させる処理の一例を示す図表である。総量制御部７９は、前記派生起動取引中断ビットがＯＮである場合には前記派生トランザクションを起動する業務処理要求の入力を中断させる派生起動取引入力中断制御機能２８を備える。派生トランザクションを起動する業務処理要求としては、例えばセンター一括処理がある。派生起動取引入力中断制御機能２８は、本実施形態では、例えば、センター一括処理を要求するセンターカット電文を入力するとき（例えば、ＳＡＩＬのＥＸＩＴ処理時）、システム状況ＤＢ８３に格納された派生起動取引中断ビットを参照し、派生起動取引中断ビットがＯＮであると、センターカット電文の入力を中断する。従って、センター一括処理自体を待機させることでシステム負荷を軽減し、且つ、センター一括処理は取消再カットメインを派生トランザクションとして起動する可能性があるため、派生トランザクションの起動を抑制することができる。
【０１７０】
また、総量制御部７９は、システム状況ＤＢ８３に格納された派生中止ビットがＯＮである場合に、派生起動要求があった時には、当該派生起動情報を前記派生管理ＤＢに登録後、派生トランザクションの起動を行わない派生起動中止制御機能３０を備える。図１８に示す例では、派生起動トランザクションを管理する派生起動要求共通処理は、派生起動情報を登録後、派生中止ビットがＯＮである場合には、派生メッセージを出力しない。すると、派生起動トランザクションがコミットし、派生トランザクションがアボートされたのと同様の状態となる。すなわち、派生起動中止制御機能３０は、派生メッセージの出力処理時にシステム状況ＤＢ８３の派生中止ビットを参照し、派生中止ビットがＯＮである場合には付随処理である派生トランザクションを起動しない。
【０１７１】
また、総量制御部７９は、前記派生中止ビットがＯＮである場合に業務処理要求を受信した場合であって、当該業務処理要求に滞留時停止指定がある場合には、当該業務処理要求の処理を不能としてエラー出力する滞留時エラー制御機能３１を備えるようにしても良い。図１３を参照すると、動作環境指定として、オペコードに続いて滞留＝Ｎｏ，センター一括＝Ｙｅｓ等の指定がある。この動作環境指定で滞留＝Ｙｅｓとなっているオペコードの処理を要求されたときに、派生中止ビットがＯＮとなっている場合には、滞留時エラー制御機能３１を備える例では、当該メッセージを処理不能としてエラーを出力する。
【０１７２】
＜派生再起動＞
次に、派生トランザクションの再起動について説明する。派生トランザクションは、アボートされた場合や、派生トランザクション実行中にシステム障害が発生した場合や、派生トランザクションの起動が中止された場合に、事後的に再起動を行う。派生トランザクションの再起動の手順を明確にすることで、派生起動トランザクションと派生トランザクションとを利用した派生利用トランザクションの実際上の原子性を保つことができる。
【０１７３】
再度図７を参照すると、演算手段４は、前記派生インデックスＤＢ６８及び派生管理ＤＢ７０を参照して派生インデックスビット及び使用中フラグがＯＮで且つ派生管理ＤＢに派生起動情報を格納した後予め定められた時間以上経過している派生管理通番を派生再起動要と判定する派生再起動要否監視部７６と、派生再起動要否監視部７６によって再起動要と判定された派生管理通番を再起動する場合には、当該派生管理通番によって特定される派生起動情報に基づいて派生トランザクションを起動すると共に当該派生管理通番へ派生起動情報を格納した時刻を更新する派生再起動制御部７７とを備えている。
【０１７４】
まず、アボートの態様を説明する。派生起動トランザクションがアボートした場合、派生起動情報が一旦格納されていたとしてもロールバックによりその更新が無効となるため、派生管理通番の使用中フラグがオフとなる。このため、派生トランザクションは起動しない（図１２，Ｓ７４）。従って、派生起動トランザクションのアボートでは派生トランザクションの再起動が必要となることはない。
【０１７５】
派生トランザクションがアボートした場合、使用中フラグを使用可に更新していたとしても、この使用可への更新はロールバックにより取り消される。従って、派生トランザクションの原子性により、派生トランザクションがアボートした場合には使用中フラグが使用中となっていることが保証される。従って、派生再起動要否監視部７６は、派生インデックスビット及び使用中フラグがＯＮで且つ派生管理ＤＢに派生起動情報を格納した後予め定められた時間以上経過している派生管理通番を派生再起動要と判定することができる。デッドロックの発見に処理開始後の経過時間による判定が極めて有効であるのと同様に、本実施形態では、派生トランザクションのアボートの判定に派生起動情報のエントリー後の経過時間を用いることで、確実に派生トランザクションのアボートを検索する。
【０１７６】
また、派生トランザクションの終了処理にて、派生インデックスビットを派生ＤＢ制御処理にて実行する場合、この派生ＤＢ制御処理がアボートしたときには、派生トランザクションによる使用中フラグの更新は成功し、すでにコミットしているため、使用中フラグがオフで、派生インデックスビットがＯＮとなる。この場合、派生トランザクションの付随業務の内容は正常にコミットしているため、派生トランザクションを再起動する必要はない。
【０１７７】
派生再起動制御部７７は、派生再起動要否監視部７６によって再起動要と判定された派生管理通番を再起動する場合には、当該派生管理通番によって特定される派生起動情報に基づいて派生トランザクションを起動すると共に当該派生管理通番での派生起動情報を格納した時刻を更新する。本実施形態では、自動的な再起動を行うのではなく、アボートした派生トランザクションの存在をオペレータに表示し、オペレータからの再起動の要求を待って再起動処理を行う。このとき、派生再起動制御部７７は、派生トランザクションの再起動時にエントリー時刻を更新する。
【０１７８】
図２１は、派生トランザクションの再実行を派生管理業務により行う構成を示すブロック図である。コンソール端末２Ａから派生再実行要求９０を受信すると、そのコマンドを解析し、特定の派生トランザクションを再起動するか、又は、アボートした全派生トランザクションを一括して再起動するかの判定を行う。派生管理通番で指定された一件の派生トランザクションを再起動する場合、派生管理業務９２は、派生管理通番から派生管理ＤＢに格納されているＦＩＦＯを特定し、このＦＩＦＯを派生管理業務９２のＦＩＦＯへセットする。そして、この派生管理業務のＦＩＦＯに基づいて派生トランザクションの起動処理を行う。派生受動業務９３として、派生トランザクションが再起動される。
【０１７９】
全トランザクションを再起動する場合、派生管理業務９２は、予め定められた数の派生トランザクションを起動すると、図２（Ｃ）に示すような形式で、派生管理業務９５を派生起動する。派生管理業務９５も、予め定められた数の派生トランザクションを起動すると、派生管理業務を派生トランザクションとして起動する。各派生管理業務が予め定められた数の再起動しか行わないのは、１つのＪＯＢ番号から起動できる派生トランザクションの数が派生管理通番の数である図８乃至図１０に示すＭ（例えば、４００＋予備）以下に制限されるためである。
【０１８０】
図２２は、派生再起動要否監視部７６による派生再起動要否判定処理の詳細構成を示すフローチャートである。この派生再起動要否判定処理は、アボートされ、且つ再起動が必要な派生トランザクションの有無を監視する処理である。この派生再起動要否判定処理は、コンソール端末２Ａからのコマンド入力により実行する。また、一定時間間隔で自動的に起動するようにしても良い。コマンド入力により実行する場合、日付変更を行う前や、また、ある処理の終了時刻の前などに実行する。また、トランザクションがアボートされるとコンソール端末２Ａにその旨が表示されるため、この表示があったときに実行するようにしても良い。
勘定系システムを例とすると、例えば他の金融機関への振込処理はある時間までに完了させなければならないため、この為替の中断を指示する為替中断コマンドの入力前に、この派生再起動要否判定処理を実行することでアボートされた派生トランザクションの有無の確認を行う。例えば、上述した承認通知処理は派生トランザクションを利用するが、この派生トランザクションがアボートされていないことを確認する。また、日付変更時には再起動が必要な派生トランザクション（付随処理）が一件もないことが必要であるため、この日付変更コマンドの入力前に派生再起動要否判定処理をコマンド入力により起動する。
図２２を参照すると、派生再起動要否監視部７６は、まず、対象インデックス領域番号を０にセットする（ステップＳ９１）。続いて、派生インデックスＤＢ７８のインデックス・ビットマップを「読み取りのみ」のモードで読み込む（ステップＳ９２）。これは、通常の派生起動トランザクションとのインデックス・ビットマップに関するコンテンションの発生を防止するためである。続いて、インデックスビットの位置を先頭（１番目）にセットする（ステップＳ９３）。そして、セットされた位置のビットを読み取り、この派生インデックスビットがＯＮ（使用中）であるか否かを判定する（ステップＳ９４）。派生インデックスビットがＯＮであれば、派生管理ＤＢの内容を読み取る（ステップＳ９５）。そして、派生起動情報のエントリー時刻を参照し、派生取引起動時刻から３０秒以上経過しているか否かを判定する（ステップＳ９６）。３０秒以上経過している場合には、再派生不要ビットがＯＮか、又は派生管理ＤＢの使用中フラグが使用可（０）であるか否かを確認する（ステップＳ９７Ａ）。
再派生不要ビットは、例えば端末折り返し連続処理などでＯＮとされている。派生インデックスビットが使用中で、派生管理ＤＢの使用中フラグがＯＦＦであるのは、派生トランザクションがコミットし、派生ＤＢ制御処理がアボートした場合であるため、派生トランザクションの再起動は不要である。ステップＳ９７Ａでノーであれば、その派生管理通番で起動された派生トランザクションについて再派生が必要と判定し、コンソール端末２Ａに、派生管理通番や、起動業務の識別コードや、派生受動業務のオペコードや、派生起動情報のエントリー日付及び時刻や、当初の業務処理要求の入力店番や端末番号や、さらに、派生取引対象口座の店番や口座番号等を出力する（ステップＳ９７Ｂ）。この再派生関連情報を参照して、オペレータは、当該派生管理通番で管理される派生トランザクションを再起動するか否か判定する。
【０１８１】
派生インデックスビットがＯＦＦである場合や（ステップＳ９４，ノー）、ＯＮであったとしても派生取引起動時刻から３０秒以上経過していない場合には（ステップＳ９６，ノー）ステップＳ９８Ａ，Ｓ９８Ｂを経由して次のインデックスビット（次の派生管理通番）の判定を行う。そして、派生取引起動時刻から３０秒以上経過していても、再派生不要ビットがＯＮであったり、また、派生トランザクションがコミットしたものの派生ＤＢ制御処理がアボートした場合（派生管理ＤＢ７０の使用中フラグが使用可）であるときも（ステップＳ９７Ａ，イエス）、次のインデックスビットの判定を行う。
ステップＳ９８Ａでは、インデックスビット位置が最終であるか否かを確認する。最終位置でなければ、ビット位置を１つずらして対応する次の派生管理通番を処理対象にセットし（ステップＳ９８Ｂ）、ステップＳ９４に処理を移す。一方、インデックスビットの位置が最終であれば、次のリージョンに対応するインデックス領域番号を判定対象とするため、対象インデックス領域番号に１を加算してセットし、ステップＳ９２に処理を移す。一方、ステップＳ９９Ａにて、すべてのインデックス領域（リージョン）の探索が完了している場合には、この派生再起動要否判定処理を終了する。
【０１８２】
図２３は、アボート又は起動中止された全ての派生トランザクションを一度のコマンドで順に再起動する処理例を示すフローチャートである。図２３に示す例では、派生再起動制御部７７は、まず、初回起動時に対象インデックス領域番号として０をセットする（ステップＳ１０１）。続いて、対象インデックス領域番号のインデックス・ビットマップのうち、使用中のビット位置を探索する（ステップＳ１０２）。使用中のビットがある場合には、その対象インデックス領域番号とビット位置とから派生管理通番を算出し、派生管理ＤＢに格納された内容を読み込む（ステップＳ１０３）。そして、使用中フラグがＯＮ（使用中）で、且つ派生トランザクションの起動時刻（派生起動情報のエントリー時刻）から５分以上経過しているか否かを判定する（ステップＳ１０４）。５分以上の経過がなければ、次に使用中である派生インデックスビットを探索する（ステップＳ１０２）。
【０１８３】
派生管理ＤＢの使用中フラグが「使用中」で、且つ派生起動情報のエントリーから５分以上経過している場合には、派生管理ＤＢ７０に格納されている派生起動情報に基づいて派生トランザクションの起動を制御する（ステップＳ１０５）。具体的には、派生管理ＤＢ７０に格納されたＦＩＦＯをセットし、派生管理ＤＢ７０に格納された派生編集番号に応じて当該ＦＩＦＯから派生メッセージを生成する。派生起動制御を行うと、再派生処理回数をインクリメントする（ステップＳ１０６）。そして、派生取引起動時刻を現時刻に変更して派生管理ＤＢを更新する。続いて、次の使用中のインデックスビットを探索する（ステップＳ１０２）。対象インデックス領域番号のインデックス・ビットマップを全て確認した場合には（ステップＳ１０２）、次の派生インデックスビットについて検討するため、対象インデックス領域番号に１を加算してセットする（ステップＳ１０８）。このとき、再派生処理回数（起動した派生トランザクションの数）が一定数（例えば、８０）を越えている場合には、再派生処理回数を０にクリアして、派生再起動処理を派生トランザクションとして起動する（ステップＳ１１１）。再起動された派生再起動処理では、初回起動時ではないためステップＳ１０１をパスし、セットされたインデックス領域番号のインデックス・ビットマップの派生トランザクションの再起動を検討する。
【０１８４】
ステップＳ１０８にて、再派生処理回数が一定数を越えていない場合には、全てのインデックス領域番号（インデックス・ビットマップ）の探索が完了したか否かを確認し（ステップＳ１１０）、未検討のインデックス・ビットマップが残っている場合には、対象インデックス領域番号に１を加算して、ステップＳ１０２に処理を移す。これにより、全てのインデックス・ビットマップについてアボートされた派生トランザクションの有無を探索することができる。
【０１８５】
上述したように第２実施形態によると、派生インデックスＤＢをＪＯＢ番号毎にアクセス可能とし、さらに、派生起動情報を派生管理ＤＢに格納するため、並列に処理されているトランザクション間のコンテンション防止し、デッドロックの発生を防止し、さらに派生管理ＤＢの再編成不要としつつ、一般的なＤＢのロック機構を用いて派生トランザクションの特性を管理することができる。
【０１８６】
【第３実施形態】
図１２に示す派生特性管理共通処理にて、ステップＳ７９を派生トランザクション内の処理とすると、デッドロックが発生する可能性がある。このデッドロックは、プログラムの構築の仕方によって回避することができるが、その回避のために適用業務プログラムのプログラマが留意すべき事項は、複雑である。このため、第３実施形態では、第２実施形態を拡張するものとして、派生ＤＢを用いつつもデッドロックの発生を回避することができる仕組みを開示する。具体的には、ステップＳ７９を派生トランザクションとは別のトランザクション（派生ＤＢ制御処理）として実行するものである。
【０１８７】
図２４は、本実施形態の構成を示すブロック図である。図２４に示すオンラインシステムは、ＡＴＭ等の端末１Ａ及び営業店端末１Ｂからネットワークを介して入力される業務処理要求を受信すると共に、コンソール端末２Ａから入力される業務処理要求（コマンド）を受信する受信手段２と、この受信手段２にて受信した業務処理要求をオンライントランザクションとして処理する演算手段４と、この演算手段４による業務処理要求の結果を記録するファイル６とを備えている。
【０１８８】
そして、ファイル６は、前記オンライントランザクション又は所定の派生トランザクションである派生起動トランザクションの実行の一部として起動される派生トランザクションの派生起動情報を派生管理通番毎に記録すると共に当該派生管理通番が使用中であるか否かを示す使用中フラグを有する派生管理ＤＢ７０と、この派生管理ＤＢ６８での派生管理通番を前記トランザクションのＪＯＢ番号を単位とした複数の派生管理通番から使用可の派生管理通番を特定すると共に前記派生管理通番が使用中であるか否かを示す派生インデックスビットを前記ＪＯＢ番号毎に複数有する派生インデックスＤＢ６８とを備えている。この派生インデックスＤＢ及び派生管理ＤＢ７０の構成及び役割については、上記第２実施形態と同様である。従って、好ましい例ではＪＯＢ番号からインデックス・ビットマップを特定し、このインデックス・ビットマップを参照して使用可の派生管理通番（派生インデックスビットのビット位置）を特定する。
【０１８９】
図２４に示す例では、演算手段４が、前記オンライントランザクション又は派生トランザクションの種類を特定するオペコードに応じて当該トランザクションを構成するプログラムの実行を管理する業務メイン処理部１００と、この業務メイン処理部１００によって呼び出されたプログラムを実行する業務処理部１１０とを備えている。ここでは、演算手段４の構成を、実際のプログラムの配分に従って、各プログラムをトランザクションとして管理する業務メイン処理部１００と、実際にプログラムを実行する業務処理部１１０とに機能分けをする。
【０１９０】
演算手段４では、ＩＭＳ上でＦＰ及びＳＡＩＬが各種のサービスを提供しているとする。図２４に示すメッセージ入力手段８（例えば、ＳＡＩＬの入力インタフェース）は、業務処理要求（入力メッセージ）を受信すると、入力メッセージ上の業務識別コード、媒体タイプ、入力編集番号をもとに入力編集定義テーブルを特定する。本実施形態では、業務識別コードと入力編集番号とはオペコードから変換する。入力インタフェースは、入力編集定義テーブルに従って、メッセージ上のデータを指定された編集を行い、編集後のデータを指定されたＦＩＦＯのフィールドへセットする。この編集の完了後、ＳＡＩＬは業務識別コードに対応した適用業務プログラムを呼び出す。本実施形態では、全業務に共通の業務メインと呼ばれるプログラムを呼び出す。
【０１９１】
業務メイン処理部１００は、図２５に示すように、業務メインの（１）開始処理を実行する。そして、例えば図１３に示すようなオペコードテーブルに基づいて適用業務プログラムを特定し、呼び出す。図２５に示す例では、業務メインは、派生起動トランザクションの一部となる派生起動ＡＰＰＬを呼び出す。すると、業務処理部１１０は、この派生起動ＡＰＰＬを実行する。この実行中に、業務処理部１１０は、派生起動要求依頼（マクロを用いる場合には、派生要求マクロ）を業務メインに入力する。
【０１９２】
業務メインは、派生起動要求依頼を受信した場合には、派生要求共通処理を呼び出す。すなわち、業務メイン処理部１００は、派生起動トランザクションの実行によって派生起動要求依頼を受信した場合には派生要求共通処理を当該派生起動トランザクションの一部として実行する派生要求共通処理呼び出し機能１０２を備えている。派生要求共通処理は、例えば図１１に示す処理である。業務処理部１１０は、この派生要求共通処理を実行する派生要求共通処理機能１１２を備える。派生要求共通処理機能１１２は、例えば、ＣＰＵが、図２５に示す派生要求共通処理指令１１２Ａを実行することで実現する。
【０１９３】
派生要求共通処理機能１１２は、図２５に示すように、派生要求共通処理が呼び出されて処理を開始すると（１）、当該派生起動ＡＰＰＬ１１１Ａがスケジュールされているリージョンでの当該トランザクションのＪＯＢ番号を特定し（２）、前記派生インデックスＤＢを参照する（３）。この参照により、前記派生管理ＤＢの派生管理通番を特定して派生インデックスビットをＯＮ（使用中）にする（４）。そして、ビット位置から派生管理通番を算出し、これを当該リージョン内のＦＩＦＯにセットする（６）。そして、派生インデックスＤＢ６８の残り個数及び派生件数を更新する（７）。さらに、派生管理通番のセグメントに派生起動情報を格納し、使用中フラグを使用中に更新する（８）。そして、派生要求共通処理は、システム状況ＤＢ８３に格納された派生中止ビットを参照し、派生中止ビットがＯＦＦであればＳＡＩＬ（ＯＳの一部）に派生起動要求（派生要求マクロ）を入力する（９）。その後、業務メインに戻る（１０）。派生中止ビットがＯＮであれば、派生要求マクロを入力せず、派生起動トランザクションをコミットさせる。
【０１９４】
派生要求マクロが出力されると、ＳＡＩＬの連動インタフェースは、起動業務識別コード・プログラムで指定した受動業務識別コード・編集番号から、派生編集定義テーブルを特定する。本実施形態では、受動業務識別コードと派生編集番号は派生受動処理（派生トランザクション）のオペコードから変換する。連動インタフェースは、派生編集定義テーブルに従って、指定された派生起動業務側ＦＩＦＯ上のデータを、指定された編集を行って派生メッセージへセットする。連動インタフェースは、派生メッセージを受信すると、入力メッセージ上の起動業務識別コード・受動業務識別コード・派生編集番号をもとに派生編集定義テーブルを特定する。連動インタフェースは、派生編集定義テーブルに従って、派生メッセージ上のデータを、指定された編集を行った後指定されたＦＩＦＯのフィールドへセットする。この編集完了後、ＳＡＩＬは業務メインを呼び出す。これにより、派生トランザクションの処理が開始される。呼び出された業務メインは、図２５に示す例では、派生特性管理共通処理指令１０４Ａを実行する。
【０１９５】
図２５に示す本実施形態では、「派生特性管理共通処理１０４Ａ」は、例えば図１２に示す処理のうち、派生インデックスビットを使用可に更新する処理を除いた部分である。図２４及び図２５に示す例では、業務メイン処理部１００が派生特性管理共通処理１０４Ａを実行する派生特性管理共通処理機能１０４を備える。
【０１９６】
派生特性管理共通処理機能１０４は、図２５に示すように、派生特性管理共通処理１０４Ａを開始すると（１）、まず、派生管理通番をキー値として派生管理ＤＢの読み込みを試みることで（２）、派生起動トランザクションとの直列性を保つ。派生管理情報の読み込みに成功すると、使用中フラグをチェックする。使用中フラグがＯＦＦであれば、派生起動トランザクションがアボートされたとして、派生受動ＡＰＰＬを呼び出さずに業務メインを終了する（４）。一方、この派生管理通番の使用中フラグが使用中である場合には、当該派生トランザクションのオペコードに応じた派生受動業務プログラムを呼び出して実行させる（４）。
【０１９７】
業務処理部１１０は、派生受動ＡＰＰＬを実行し、終了すると、業務メインに処理を戻す。派生特性管理共通処理は、派生受動ＡＰＰＬが終了した後に、前記派生管理ＤＢの使用中フラグをオフに更新して（６）、さらに所定の派生ＤＢ制御処理を派生トランザクションとして起動させる（７）。ＳＡＩＬは、派生トランザクションのＦＩＦＯを参照して所定の編集定義に基づいて派生メッセージを出力する。派生メッセージがスケジュールされると、派生ＤＢ制御処理が実行される。
【０１９８】
前記業務処理部１１０は、派生インデックスビットを使用可へと更新する派生ＤＢ制御処理を派生トランザクションとはさらに別のトランザクションとして実行する派生ＤＢ制御処理機能１１４を備えている。派生ＤＢ制御処理機能１１４は、ＣＰＵが派生ＤＢ制御処理指令１１４Ａを実行することで実現する。派生ＤＢ制御処理１１４Ａでは、まず、派生管理通番から派生インデックスＤＢ６８のインデックス領域番号とビット位置とを算出する（２）。そして、算出したインデックス領域番号をキー値として派生インデックスＤＢ６８のインデックス・ビットマップを読み込む（３）。続いて、派生管理通番をキー値として派生管理ＤＢ７０を読み込む（４）。この派生管理ＤＢの読み込みにより、派生特性管理共通処理１１２Ａとの直列性が維持される。そして、派生管理ＤＢの使用中フラグがＯＦＦであるか否かを確認し、ＯＦＦの場合に派生インデックスビットをＯＦＦ（使用可）にして派生インデックスＤＢを更新する。
【０１９９】
図２６は、派生トランザクションの一部として、派生トランザクションの完了時に派生インデックスＤＢの派生インデックスビットをＯＦＦとした場合に、生じる可能性があるデッドロックの一例を示す説明図である。すなわち、派生インデックスＤＢ６８を用いて派生管理通番を特定する派生ＤＢ制御処理を派生トランザクションと別のトランザクションとしない場合に生じる可能性のあるデッドロックの態様の一例を示す図である。
【０２００】
デッドロックは、２つのトランザクションが相互に相手方の処理の完了を待機する場合に生じる。例えば、トランザクションＴ１がＤＢｘを読み込み、これをロックした後、次に派生インデックスＤＢ６８を読み込もうとする。一方、トランザクションＴ２が派生インデックスＤＢ６８を読み込み、これをロックした後、次にＤＢｘを読み込もうとしたとする。トランザクションＴ１が派生インデックスＤＢ６８を読み込もうとしたときに、この派生インデックスＤＢ６８がトランザクションＴ２によってロックされている場合に、トランザクションＴ１とＴ２はデッドロックとなる。
【０２０１】
図２６に示す例では、まず、ＪＯＢＦＰ０００から派生起動要求が出力され、この派生トランザクションＴ２はＪＯＢＦＰ００１にスケジュールされた。トランザクションＴ２では、別のオペコードに連動するが、連動先ではあるＤＢｘをキーｙで読み込む。トランザクションＴ２は連動処理が完了してから、派生トランザクションの後処理（派生特性管理共通処理）として、派生管理ＤＢの使用中フラグをＯＦＦとし、派生インデックスＤＢの派生インデックスビットをＯＦＦとする。このとき、派生インデックスＤＢのキー値は、インデックス領域番号であるから、トランザクション１のＪＯＢ番号である０がキー値となる。派生管理ＤＢのキー値（派生管理通番）は、ここでは１とする。
【０２０２】
トランザクションＴ２の処理中に、トランザクションＴ３がＪＯＢＦＰ０００でスケジュールされた。トランザクションＴ３では、別オペコードに連動するが、連動先では派生トランザクションを起動するため、派生インデックスＤＢをキー値を０として読み、派生管理ＤＢの派生管理通番１のセグメントに派生起動情報を格納する。トランザクションＴ３では、連動処理が完了してから、ＤＢｘを読み込む。
【０２０３】
さて、トランザクションＴ２では、ＤＢｘを読み取った後、派生インデックスＤＢをキー値０として読み取ろうとする。トランザクション３では、派生インデックスＤＢを読み取った後、ＤＢｘを読みに行く。このため、トランザクションＴ２にて連動受動処理がＤＢｘを読み込んでロックした後、派生インデックスＤＢを読み取る前のタイミングで、トランザクションＴ３が派生インデックスＤＢを読み取ると、デッドロックとなる。また、トランザクションＴ３が派生インデックスＤＢを読み取った後、連動処理が完了してＤＢｘを読み取る前のタイミングで、トランザクションＴ２がＤＢｘを読み取ると、デッドロックが生じる。
【０２０４】
デッドロックの発生を完全に防止する手法は、並列処理を行わないことであるが、これは採用できない。ロックに関しては、並列処理の直列化を維持するために、あるトランザクションは、ロックを取得するフェーズと、ロックを解放するフェーズとの２相ロッキングプロトコルに従う必要がある。従って、一度ロックを解放すると、そのトランザクションはロックを取得してはならない。この２相ロッキングプロトコルの要件によると、デッドロックが生じた場合には一方のトランザクションをアボートしなければならない。
【０２０５】
デッドロックを回避しつつ、並列性も維持する方法は、トランザクションのロックの順序を調整することである。例えば、全てのトランザクションが同一の順序でロックを要求すれば、デッドロックを回避することができる。しかし、これはプログラマにとって厳しい制限となる。また、トランザクションが使用する全てのロックをその開始時に取得してから、実際の処理を行うことによっても、デッドロックの発生を回避することができるが、この場合、限りなく直列処理に近くなり、並列処理の利点が減少する。
【０２０６】
これらの標準的な手法でデッドロックを回避するためには、「派生トランザクションを起動する可能性がある連動受動処理に連動する前に、連動後に読むＤＢを連動前に読んでおく」必要がある。これにより、実行順序が同一となる。全ての連動起動処理がこの条件を満たすのであれば、図２６に示すデッドロックの発生を回避することができる。しかしながら、連動起動業務の開発者が、このＤＢの読み込み順序を守るよう意識するのは、負担が大きく、困難である。
【０２０７】
このため、第３実施形態では、派生ＤＢ制御処理として、派生インデックスＤＢの派生インデックスビットをＯＦＦにする処理を別トランザクションとしている。このため、派生特性管理共通処理では、派生インデックスＤＢの派生インデックスビットの更新を行わない。従って、１つのトランザクション内でＤＢｘのロックと派生インデックスＤＢのロックとを行うことがなくなる。派生ＤＢ制御処理は、派生ＤＢ（派生管理ＤＢと派生インデックスＤＢ）以外のＤＢを読み込まないため、デッドロックは生じない。
【０２０８】
再度図２５を参照して、本実施形態での派生トランザクション管理方法を説明する。派生トランザクション管理方法は、派生起動トランザクション（派生起動ＡＰＰＬ１１１Ａ）を実行すると共に、当該派生起動トランザクションによって起動要求依頼される派生トランザクション（派生受動ＡＰＰＬ１１３Ａ）のコミットを待機せずに当該派生起動トランザクションをコミットさせる派生起動トランザクション管理工程（１００Ａ，１１２Ａ）と、派生起動ＡＰＰＬ１１１Ａによって起動要求依頼された派生トランザクションを管理する派生トランザクション管理工程（派生特性管理共通処理１０４Ａ）と、この派生トランザクション管理工程にて派生トランザクションとして起動される派生ＤＢ管理工程（派生ＤＢ制御処理１１４Ａ）とを備えている。
【０２０９】
前記派生起動トランザクション管理工程は、当該派生起動トランザクションの一部として、当該派生起動トランザクションのＪＯＢ番号に応じて前記派生インデックスＤＢを参照し、前記派生管理ＤＢの派生管理通番を特定し、当該派生管理通番のセグメントに派生起動情報を格納し、当該使用した派生管理通番に対応する前記インデックスビット及び使用中フラグをそれぞれ使用中に更新して、当該派生トランザクションを起動させる派生要求共通処理工程（派生要求共通処理１１２Ａ）を備えている。
【０２１０】
そして、派生トランザクション管理工程は、前記派生トランザクションの一部として、派生要求共通処理工程１１２Ａにて派生トランザクションが起動されスケジュールされた場合に、当該派生トランザクションに与えられた派生管理通番をキー値として派生管理ＤＢを読み込み、当該派生管理通番の使用中フラグが使用中である場合には当該派生トランザクションのオペコードに応じた派生受動業務プログラムを実行させ、この派生受動業務プログラムが終了した後に前記派生管理ＤＢの使用中フラグをオフに更新して、さらに所定の派生ＤＢ制御処理を派生トランザクションとして起動させる派生特性管理共通処理工程（派生特性管理共通処理指令１０４Ａ）を備えている。この派生特性管理共通処理工程にて、インデックス・ビットマップの更新を行わないため、図２６に示すデッドロックが生じない。
【０２１１】
そして、派生ＤＢ管理工程は、前記派生ＤＢ制御処理がスケジュールされた場合に、前記派生受動業務プログラムを含む派生トランザクションを再起動するための派生起動情報が格納された派生管理ＤＢの派生管理通番に対応する前記派生インデックスＤＢの前記派生インデックスビットを使用可に更新する派生ＤＢ制御処理工程（派生ＤＢ制御処理指令１１４Ａ）を備える。派生ＤＢ制御処理工程では、１つのとして、インデックス・ビットマップの更新のみを行うため、他のトランザクションのロックの待機を行うことはあっても、デッドロックを生じることはない。また、派生ＤＢ制御処理による派生ＤＢ制御トランザクションは、図２５に示す例では、派生特性管理共通処理１０４Ａによって指定された派生管理通番にて派生管理ＤＢ７０を読み取るため、派生特性管理共通処理１０４Ａとの直列性を有する。すなわち、派生特性管理共通処理が正常にコミットした後に、インデックス・ビットマップを更新する。従って、並列処理によってシステム的な一貫性が失われることはない。
【０２１２】
また、図２４に示すように、第３実施形態においても総量制御部１４の各構成を備えるようにしても良い。第３実施形態では、システム負荷が大きい場合には、派生ＤＢ制御処理の起動を中止し、滞留の解消後に一括して派生インデックスビットをオフにする処理を行うようにしても良い。
【０２１３】
第３実施形態では、アボートされた派生トランザクションの再起動は、第２実施形態と同様である。業務メイン１００Ａ，派生起動ＡＰＰＬがアボートした場合には、使用中フラグ，派生インデックスビット共に使用可のままであり、派生トランザクションの起動要求もなされない。派生要求共通処理１１２Ａにて派生ＤＢ６８，７０の更新後、派生起動要求の出力前にアボートされた場合には、使用中フラグ及び派生インデックスビットは更新されるものの、ロールバックによってこの更新がなかったものとなる。そして、派生トランザクションもスケジュールされない。
【０２１４】
派生起動要求の出力後に派生要求共通処理１１２Ａや、業務メイン１００Ａや、派生起動ＡＰＰＬ１１１Ａが連動受動業務の場合で連動戻り後の連動起動業務の処理がアボートした場合にも、ロールバックによって派生要求共通処理のＤＢへの更新が無かったものとなる。しかし、派生メッセージはスケジュールされている可能性がある。この場合、派生特性管理共通処理１０４Ａ（３）にて使用中フラグをチェックする。使用中フラグを読み込めた時には派生起動トランザクションはアボートしている。このため、ロールバックによって更新されない状態の使用中フラグを読み取ることとなる。従って、派生特性管理共通処理１０４Ａ（３）では、使用中フラグが「使用可」であるため、派生受動ＡＰＰＬを呼び出さずに処理を終了する。この場合、派生起動トランザクションも派生トランザクションも無かったこととなる。
【０２１５】
派生起動トランザクションがコミットすると、使用中フラグが「使用中」の状態で派生管理ＤＢに耐久性を持って記録される。派生特性管理共通処理１０４Ａの（１）から（５）までと、派生受動ＡＰＰＬのアボートの場合、派生管理ＤＢの使用中フラグは使用中のままであり、派生インデックスＤＢも使用中のままである。派生受動ＡＰＰＬが完了後、派生特性管理共通処理が使用中フラグをオフにした後にアボートした場合や、さらに派生トランザクションを起動するための派生要求共通処理１１２Ａ等の処理中にアボートした場合には、ロールバックによって派生特性管理共通処理の更新が無かったものとなる。従って、使用中フラグは使用中（１）のままである。
【０２１６】
派生特性管理共通処理がコミットした後、派生ＤＢ制御処理がアボートしたとする。この場合、使用中フラグはオフとなっている。しかし、派生インデックスＤＢの派生インデックスビットはＯＮのままである。このように、（１）．派生起動トランザクションのアボートの場合には、派生トランザクションは起動しない。（２）．派生トランザクションがコミットしたが、派生受動ＡＰＰＬ１１３Ａや派生特性管理共通処理１０４Ａがアボートした場合には、使用中フラグ及び派生インデックスビットが共に使用中のままである。（３）．派生トランザクションもコミットしたが、派生ＤＢ制御処理１１４Ａがアボートした場合には、使用中フラグが使用可で、派生インデックスビットがＯＮの状態である。
【０２１７】
派生トランザクションの再起動が必要となるのは、（２）．の場合である。従って、使用中フラグがＯＮで、起動と一定時間が経過している処理を探索することで、再起動の要否を判定すべき派生トランザクションを特定することができる。（３）．の派生ＤＢ制御処理１１４Ａのアボートの場合には、派生受動ＡＰＰＬ及び派生特性管理共通処理１０４Ａは正常にコミットしているため、派生トランザクションを再起動する必要はない。
【０２１８】
上述したように本実施形態によると、派生と連動とが複雑に絡み合った状態で生じるデッドロックを派生ＤＢ制御処理によって回避することができるため、開発者がプログラム作成上の調整を行う必要がなくなる。
【０２１９】
【発明の効果】
本発明は、その構成によって、オンライン応答が必要なオンライントランザクションと、オンライントランザクション等に付随した処理を実行する派生トランザクションとに区分けされて実行される。このため、オンライン応答に必要な処理をオンライントランザクションとして処理し、オンライン応答に必要のない付随処理を派生トランザクションとしてオンライントランザクションのコミット後に処理する。従って、オンライントランザクションを早期にコミットさせることができる。これにより、オンラインの応答性を確保しつつ、付随的な業務のみを事後的に派生トランザクションとして処理することができる。従って、従来バッチ処理で行っていたような処理について派生トランザクションを利用してオンライントランザクションと並行した処理が可能となる。このように、本発明によると、派生トランザクションモデルを用いることで、従来バッチ処理等で実現していた処理や、１つのトランザクションとしては処理量が多くなる処理を実行しつつ、オンラインの応答性を確保することができる、というトランザクション制御システムを実現することができる。
【図面の簡単な説明】
【図１】図１は本実施形態によるオンライントランザクション制御システムの構成を示すブロック図である。
【図２】図２は、派生トランザクションの性質を説明する説明図であり、図２（Ａ）は、派生起動トランザクションから派生トランザクションの起動要求がなされる例を示す図で、図２（Ｂ）は、派生起動トランザクションが連動トランザクションである場合を示す図で、図２（Ｃ）は、派生トランザクションが自らを派生トランザクションとして起動要求する例を示す図である。
【図３】図３は派生トランザクションの利用法に応じた端末応答等を説明するための説明図であり、図３（Ａ）は、付随業務の場合を示す図で、図３（Ｂ）は取消再カットメインの場合を示す図である。
【図４】図４は、取消再カットメインの動作例を示す説明図である。
【図５】図５は端末折り返し連続処理に派生トランザクションを用いた例を示す説明図である。
【図６】図６は、トランザクションの総量制御の一例を示すフローチャートである。
【図７】図７は、第２実施形態の構成を示すブロック図である。
【図８】図８は、ＪＯＢと派生インデックスＤＢ等との関係を示す説明図である。
【図９】図９は、派生ＤＢのデータ項目を例示する説明図であり、図９（Ａ）は派生インデックスＤＢの項目例を示す図で、図９（Ｂ）は派生管理ＤＢの項目例を示す図である。
【図１０】図１０は、ＪＯＢ ＩＤと、派生インデックスＤＢのインデックス領域番号と、ビット位置と、派生管理通番との関係を例示する説明図であり、図１０（Ａ）はＪＯＢ ＩＤ０００で実行されているトランザクションによって読み出される派生インデックスＤＢとそのビット位置及び派生管理通番の関係を示す図で、図１０（Ｂ）はこの場合の派生管理ＤＢの内容の例を示す図で、図１０（Ｃ）はＪＯＢ ＩＤ００１で実行されているトランザクションによって読み出される派生インデックスＤＢとそのビット位置及び派生管理通番の関係を示す図で、図１０（Ｄ）はこの場合の派生管理ＤＢの内容例を示す図である。
【図１１】図１１は、派生トランザクションの要求を管理するための派生要求管理処理の一例を示すフローチャートである。
【図１２】図１２は、派生トランザクションの特性を管理するための派生特性管理処理の一例を示すフローチャートである。
【図１３】図１３は、オペコードテーブルの一例を示す図で、ここでは普通預金のオペコードテーブルを例示する。
【図１４】図１４は、取消再カットメインでの処理例を示す説明図であり、図１４（Ａ）は口座処理による電気料引落（内部自振）の取消を行う例を示す図で、図１４（Ｂ）はその処理による残高の推移を示す図である。
【図１５】図１５は、図１４に示した処理でのＦＩＦＯ推移及び派生メッセージの例を示す説明図である。
【図１６】図１６は、図１５に続くＦＩＦＯ等の推移を示す説明図である。
【図１７】図１７は、図１４及び図１５に示す例での派生ＤＢの利用例を示す説明図である。
【図１８】図１８は、ＪＯＢを一般トランザクションと派生トランザクションとに別々に割り当てる例を示す説明図である。
【図１９】図１９は、滞留監視処理の一例を示すフローチャートである。
【図２０】図２０は、派生トランザクションの実行を待機させる総量制御処理の例を示す図表である。
【図２１】図２１は、アボートされた派生トランザクションの再起動処理の一例を示すブロック図である。
【図２２】図２２は、派生トランザクションの再起動の要否を判定する処理の一例を示すフローチャートである。
【図２３】図２３は、派生トランザクションの再起動処理の一例を示すフローチャートである。
【図２４】図２４は、第３実施形態の構成を示すブロック図である、
【図２５】図２５は、派生管理処理の構成を示す説明図である。
【図２６】図２６は、派生ＤＢ制御処理を別トランザクションとしない場合に生じる可能性のあるデッドロックの態様の一例を示す説明図である。
【符号の説明】
２ 受信手段
４ 演算手段
６ ファイル
８ メッセージ入力手段
１０ オンライン応答部
１２ 派生トランザクション管理部
１４ 総量制御部
１６ トランザクション実行部[0001]
BACKGROUND OF THE INVENTION
The present inventionGThe present invention relates to a transaction control system and method.
[0002]
[Prior art]
Conventionally, transaction processing has been used as a method for realizing processing that is accurate and consistent with a large-scale database and enables reliable recovery from a failure. A transaction is used as a unit of processing for a database (DB). The transaction performs one or more updates to the DB. At this time, the nature of the transaction is guaranteed to either succeed as a whole or fail as a whole. A transaction reaches a syncpoint when all updates to the DB are successful. That is, the transaction commits. In a general transaction management system, an update by a transaction that reaches a synchronization point is recorded in a log, and the update to the DB has durability against a failure.
[0003]
On the other hand, if even one of the processes included in the transaction is not established, the transaction is aborted. When a transaction is aborted, all updates made by that transaction are canceled. That is, when a transaction is aborted, the transaction management system rolls back all the updates executed up to that time. For this reason, even if a transaction executes one or more programs and performs multiple updates, either all updates are executed normally and committed, or no processing is performed by rollback. It is. Since a transaction is the smallest unit of processing for an application, this is called transaction atomicity.
[0004]
Since the transaction has atomicity, the programmer can maintain consistency and consistency when updating the DB. The programmer of the application program (application, APPL) performs a process of calculating intermediate data that should not be referred to by other transactions and a process of converting or relating this intermediate data to normal data. By wrapping it as one transaction, it is possible to maintain the consistency of the DB and the consistency of the data. Since the commit is performed on the condition that the data has been converted into normal data, the data is stored in the DB in an intermediate data state, and the intermediate data is not referred to by other transactions. On the other hand, if the data is not converted to normal data, the transaction is aborted, so that intermediate data calculation and update are also canceled by rollback.
[0005]
For example, account transfer (fund transfer) is a process consisting of subtraction (withdrawal) of a numerical value from a certain account A and addition (payment) of a numerical value to another account B. The intermediate data is, for example, subtraction of a numerical value from a certain account A. By wrapping the numerical value subtraction process and the addition process as one transaction, it is guaranteed that the account transfer is either successful or unsuccessful. In this case, only numerical subtraction or addition is not performed. That is, when the withdrawal and deposit are processed as one transaction, there is no situation where only withdrawal is performed and no deposit is made.
[0006]
In addition, a plurality of transactions can be processed in parallel by maintaining a clear relationship between transactions and preventing other transactions from referring to data being processed. Thus, in order to perform parallel processing or distributed processing, data handled between transactions must be isolated from each other. Locking is effective for this data isolation. When a transaction accesses data with the possibility of updating, the transaction locks the data item, performs the necessary update, and then releases the lock. When a transaction attempts to access locked data, it waits until the lock is released by another transaction. As a result, transaction seriality is ensured, transaction isolation is provided, and transaction parallel processing and distributed processing are possible.
[0007]
By using locks, parallel processing can be performed while maintaining the seriality of transactions, but if the lock granularity (unit of contention) is large, the frequency of waiting for lock release increases and waits Time tends to be longer. Further, in the example using the lock, a deadlock occurs depending on the DB reading order of each transaction. For example, when there is DBx and DBy, the transaction T1 reads DBx, and then tries to read DBy, but this DBy is locked by the transaction T2. In this case, the transaction T1 waits until the DBy lock is released while the DBx is locked. If transaction T2 tries to read DBx after reading DBy, a deadlock occurs. In this way, a deadlock occurs when the transaction T1 waits for the completion of the processing of T2 and the transaction T2 waits for the completion of the processing of T1. Deadlock can be avoided by making the DB reading order the same in all transactions.
[0008]
Now, transactions have ACID characteristics of atomicity, consistency, isolation, and durability. By using transaction processing based on this characteristic, a strict and robust system can be constructed. Therefore, transaction processing systems are used in a wide range of fields, such as accounting systems at financial institutions, management systems for aircraft operation and ticketing, manufacturing process management systems for various industries, and communication control systems. Yes. Such a system performs online processing and batch processing. For example, in a conventional accounting system, business processing requests from terminals such as ATMs and branch office terminals are processed as online transactions during the day, and account transfers are processed in batches from the night when online is stopped to early morning. It was.
However, today, there is a demand for continuous operation for 24 hours by minimizing batch processing.
[0009]
Businesses that can be executed by transactions having ACID characteristics have been limited to relatively simple processing. This is because when a complicated process is executed in one transaction, a lot of locks are generated, and the responsiveness of the online process is deteriorated. In addition, there is a data amount that cannot be processed in one transaction. Conventional transaction processing is generally programmed to receive an online business processing request, execute it immediately, and commit immediately.
[0010]
If locking for managing the seriality between transactions is not performed, the responsiveness is improved, but the consistency of the DB cannot be strictly managed. Although there is a compromise based on wisdom for a good design, various attempts have been made in recent years to achieve both on-line responsiveness and more complicated processing. This conflict is related to how to reconcile transaction parallelism with strict atomicity. If parallel processing can function effectively, online transaction responsiveness is ensured well.
[0011]
Several approaches to this challenge are, for example, “Introduction to Transaction Processing Systems” by Philip A. Bernstein and Eric Newcomer, published by Nikkei BP (Principles of Transaction Processing, Philip Bernstein, Eric Newcomer) and “CORBA, Enterprise Transactions by Encina "written by Ian Gorton, published by Pearson Education (Enterprise Transaction Processing Systems: Putting the CORBA OTS, Encina ++ and Orbix OTM to Work, Ian Gorton).
[0012]
There is a save point as a method that goes beyond simple transaction management based on the ACID characteristic. This saves the state of all resources during the execution of a transaction. This makes it possible to resume from the middle of a transaction when a failure occurs. Persistent savepoints give durability without the atomicity of transactions. As a result, a transaction that takes a long time to process can be resumed from the middle instead of aborting the entire transaction. A technique using save points is disclosed in, for example, Japanese Patent Application Laid-Open No. 2000-10810. In general, even if a savepoint is used, the data handled by the transaction at the time of the savepoint is isolated from other transactions, so it is not possible to reduce lock contention.
[0013]
There are nested transactions (for example, Transarc's Encina TP monitor) and chained transactions (for example, IBM's MQ series) as methods for associating multiple transactions. Nested transactions can call other transactions during transaction execution by giving parent-child relationships to transactions. The first transaction started is the parent transaction. The transaction called by this parent transaction becomes a sub-transaction. The secondary transaction has ACID characteristics for the parent transaction, but is not durable for other transactions. The secondary transaction finally commits when the parent transaction commits. A subtransaction is atomic with respect to other subtransactions with the same parent and is isolated from other transactions and subtransactions with the same parent.
[0014]
Using this nested transaction model, a parent transaction called transfer processing can start a sub-transaction called withdrawal processing and a sub-transaction called payment processing. When a sub-transaction called withdrawal process commits, the result can be referred to from the deposit process. On the other hand, the lock manager moves to the parent transaction by committing the sub-transaction, which is a withdrawal process. For this reason, until the parent transaction commits, other transactions than the sub-transaction cannot refer to the result of the withdrawal process. Accordingly, when the deposit process is aborted for some reason, the parent transaction is aborted and the withdrawal process can be rolled back. This nested transaction model is said to be compatible with object-oriented programming.
[0015]
Using the nested transaction model, it is possible to develop a system by defining complex data structures and processes in the class hierarchy and defining the message and behavior of the object, but the parent transaction is actually committed by the parent transaction. Since durability is not given until then, an increase in lock may occur. That is, in the nested transaction model, a large transaction including a sub-transaction is executed, and the global transaction has ACID characteristics with respect to other transactions. Therefore, the nested transaction is useful for improving the reusability of the program, but does not reduce lock contention in units of the parent transaction.
[0016]
The term “chain” is used in various contexts. In Japanese Patent Laid-Open No. 10-69418, a chain transaction is described in paragraphs 0060 and below. According to this, in the chain transaction model, the member transaction T3 starts another member transaction T4. The starting process of the member transaction T4 is wrapped in the atomicity of the starting member transaction T3. Therefore, another member transaction T4 is activated only when the invoking member transaction T3 commits. The abort of the activated member transaction T4 does not affect the transaction T3.
[0017]
The restart handling by the chained transaction method is executed by reestablishing the commit state of the recently committed member transaction. In this chain transaction model, the commit of the transaction T3 can be accelerated. That is, transaction T3 can commit without waiting for transaction T4 to commit.. oneOn the other hand, in the chained transaction model, global transactions do not have ACID characteristics. Therefore, atomicity is not strict in the chained transaction model.
[0018]
There is a fast path (FP) method as a method for improving the processing speed including ensuring online responsiveness. For example, in JP-A-6-195250, in a system in which a high-speed path system is mounted on an IMS of IBM, an active database copy is continuously maintained in a backup system for recovery in the event of a failure. The method is disclosed. The FP is used to improve responsiveness particularly in an online system in a financial institution, and various restrictions are imposed on resources for the purpose of improving the processing speed. For example, FP does not use look-aside database buffers, which are temporary storage areas commonly used in IMS databases, and also limits the number of database buffers that can be used in one transaction. . Further, in IMS, a message that is a business process request is stored in a message queue, but in FP, the queuing system is bypassed and a transaction is transmitted from a terminal via a simpler queue (not recoverable). Can be sent to the program. These improve online responsiveness.
[0019]
[Problems to be solved by the invention]
Recent online systems are required to operate continuously 24 hours a day, 365 days a year. Therefore, it is desirable to process batch processing in parallel with online processing. That is, it is required to reconstruct a conventional batch process as an online process. In general, since batch processing is executed on the premise of a static state of the DB, the batch processing itself cannot be executed while the contents of the DB are changing due to an online response. When a process based on a static state is to be executed in a dynamic state, a situation similar to a chain abort may occur.
[0020]
Cascading abort is a detrimental effect when the transaction consistency and seriality are lost. For example, after the value of DB is updated from x to y, a plurality of transactions are executed based on y that is the updated value. Thereafter, the update from x to y is canceled. Alternatively, it is assumed that the value is updated from y to z. Then, all transactions established on the premise of y must be canceled and re-executed. When a transaction abort occurs, a further transaction abort is chained. This situation must be avoided. However, when trying to process batch processing in parallel with online during the day, a situation similar to such a chain abort may occur. For example, when the account transfer performed based on the last balance of the previous day is processed during the day of the previous day, there is a possibility that the final balance of the previous day that has been assumed will change. If there is a change in the account balance after the account transfer process, it may appear that the situation is similar to a situation where a chain abort occurs.
[0021]
As described above, when trying to execute the batch process as an online process during the day, it is necessary to perform various processes in a state where the DB is not stationary. Therefore, it is necessary to strictly manage consistency and seriality. This problem is a common problem in development that attempts to execute batch processing as daytime online processing in various application fields as well as account transfer.
[0022]
In the chained transaction model, processing that responds to a terminal is committed, and another transaction can be executed thereafter, so that both online responsiveness and complex processing can be realized. However, in terms of bringing batch processing online, it is necessary to take measures when processing requests are concentrated and for the situation that can be a chain abort described above. In addition, the chained transaction model is not standardized and may not be used in all transaction management systems.
[0023]
The above Japanese Patent Laid-Open No. 10-69418 discloses that the ACID characteristic is added to the global transaction while using the chained transaction model in a hierarchy, but the relationship between the abort of the member transaction and the atomicity of the global transaction is disclosed. Is not disclosed.
[0024]
In order to ensure online responsiveness, it is desirable to employ a high-speed path (FP). However, when FP is used, the number of buffers in the database is limited, and there are certain limitations such as inability to recover from the queue. For example, the amount of processing that can be processed in one transaction with ACID characteristics is limited. End up. For example, when an FP is adopted for an interlocking transaction in which a plurality of processes are interlocked in one transaction as in the case of a nested transaction, the number of interlocking that can be executed in one transaction is limited.
[0025]
OBJECT OF THE INVENTION
The present invention improves the inconvenience of such a conventional example, and in particular while ensuring the responsiveness of online processing.complexityCan be realizedRutoTransaction control system,MethodAnd programsThe purpose is to provide
[0026]
[Means for Solving the Problems]
In the present invention, a derived transaction model is used. The derived transaction executes a business associated with the main transaction. By preparing a transaction model for processing incidental work, the programmer of an application program can change the program as a transaction having normal ACID characteristics, except for incidental work not related to online responses. It is possible to construct a program by using a subsidiary transaction as a derived transaction. Then, the transaction executing the business process makes a request for starting the derived transaction during the execution, and then returns a response to the terminal without waiting for the completion of the processing of the derived transaction.
[0027]
In the present invention, the endEndReceiving means for receiving a business processing request input via a network, computing means for processing the business processing request received by the receiving means, and this computing meansWhereAnd a file for recording the results.
And the computing means isA transaction execution unit, an online response unit, and a derived transaction management unit are provided.
The transaction execution unit executes a predetermined online transaction and a predetermined derived transaction in parallel, and locks and processes the data item of the file and records the processing result in the file when executing each transaction. The lock is released after the recording.
The online response unit controls the transaction execution unit to process a business process request input from the terminal as an online transaction, and outputs a processing result of the online transaction as a response to the terminal.
The derived transaction management unit causes the transaction execution unit to process the derived transaction and manages the commit of each transaction. Further, when a request for starting a new derived transaction is output during execution of each of the transactions, the derived transaction management unit uses the transaction that output the start request as a derived start transaction and performs the following control. I do. That is, control is performed to wrap the request for starting the derived transaction into the atomicity of the derived start transaction. Subsequently, the derivative activation transaction is committed without waiting for the commit of the derivative transaction requested to be activated.
In the transaction control system according to the present invention, the derivation transaction is requested to be activated during execution of the derivation activation transaction, andIt is a transaction for processing all or a part of the incidental business that occurs accompanying the processing result of the line transaction and is not necessary for the response of the online transaction.
In the present invention, in particular, the derived transaction management unit manages the start and start of the derived transaction.
That is, when the activation request is output, the derived transaction management unit records the derived activation information related to the derived transaction activation request in the file, and records the derived activation information in the derived activation A derivative activation information storage control function for managing the activation of a derivative transaction is provided by performing control encompassing the atomicity of the transaction.
Further, the derived transaction management unit has a function of committing the derived activation transaction without waiting for the start of the derived transaction requested to be activated.
In addition, the derivative transaction management unit allows access to the unlocked data item by another online transaction by releasing the lock by the derivative activation transaction when the derivative activation transaction is committed, A seriality management function that manages the start of the derived transaction by starting the process of the derived transaction requested to be activated.It has a configuration that it is equipped. Thus, the above-described problem is to be solved.
[0028]
The online response unit processes the business process request as an online transaction and outputs the response to the terminal. The online transaction may be a business process request generated by operating a terminal used by a customer, or may be a business process request corresponding to a process performed in an internal batch process. “Output the processing result as a response to the terminal” means that a response is output to the terminal when an output to the terminal (or a pseudo terminal) is requested as part of the execution of the online transaction. Thus, not all transactions return a response to the terminal.
[0029]
Derived transactions process incidental business related to business processing by online transactions. Ancillary work is work that does not require an online response to an online transaction, and is generally a business that accompanies the main business. is there. Derived transactions are invoked by programs during the execution of online transactions. Further, the derived transaction may start another derived transaction. The derived activation management function causes the derived activation transaction to be committed without waiting for the commit of the derived transaction. That is, the business process is completed without waiting for the completion of the accompanying business. Even if the derived transaction aborts, the derived start transaction is not canceled.
[0030]
As described above, in the present invention, the chain transaction model is applied to the division between the main business process and the incidental business process. Thus, the online transaction can be committed at an early stage by processing the process necessary for the online response with the online transaction and processing the accompanying process that is not required for the online response as the derived transaction. That is, it is possible to perform complicated processing as a whole by processing only incidental work as derived transactions afterwards while ensuring online responsiveness.
[0031]
Further, depending on the situation, the derived transaction can be a derived activation transaction. In this case, the incidental business is executed by repeating the derived transaction without processing it in one transaction. In the example in which this derived transaction is repeatedly activated and executed, each derived transaction commits individually, so that the processing amount processed by one transaction is relatively small, and the lock is once released by the commit. For this reason, it does not cause a high load on the system while performing a complicated incidental operation.
[0032]
A process (derived transaction) composed of a derived activation transaction and a derived transaction does not satisfy the ACID characteristic. That is, there may be a situation where the derivative invocation transaction has committed but the derivative transaction is aborted. On the other hand, if the derived activation transaction does not commit, the derived transaction is not executed. That is, although the business process itself that requires an accompanying task has not yet been established, only the accompanying task is not established. When the business process is established and the accompanying business is not established, the derivative transaction for processing the accompanying business is restarted. To realize these mechanisms, FactionWhen the raw transaction management unit aborts the derived activation information storage control function for committing the derived activation transaction after storing the derived activation information related to the activation request of the derived transaction in the file, and A seriality management function for controlling the derivative transaction not to start or commit;Is provided. In a preferred embodiment,Derivative restart control function for restarting the derived transaction based on the derived activation information when the derived transaction aborts after the derived activation transaction is committedThePrepareAnd good.
[0033]
The derivative activation information storage control function stores, in a file, the derivative activation transaction that is requesting activation of the derivative transaction and the data passed from the derivative activation transaction to the derivative transaction as derivative activation information. To do. This derived activation information is not used in normal processing, but is used when the derived transaction aborts and only the derived transaction is restarted. That is, the derivative restart control function restarts the derivative transaction based on the derivative activation information when the derivative transaction aborts after the derivative activation transaction is committed.
[0034]
In the present invention having a derivative activation information storage control function and the like, a function for controlling the restart of a derivative transaction is provided separately from the restart process when a transaction is aborted due to a general failure or the like. In this case, when the derived activation transaction and the derived transaction are considered as one, they do not have the ACID characteristic, so that the handling at the time of abort of the derived transaction is performed more strictly. The derived transaction is activated based on the derived activation information. Therefore, if this derived activation information is stored in a file in a durable state, the derived transaction can be reactivated in the same state as at the time of initial activation. Compared to restart using a queuing model or log, it is easier to find the target of restart processing, and even if an abort is caused by a bug in a derived transaction application, it can be restarted after correcting the application program. Handling can be determined flexibly, such as being executable. In addition, since the derived transaction processes an accompanying job, it can be assumed that restarting is unnecessary depending on the situation. Even when the operator determines whether or not restarting is necessary, by including various information related to starting the derived transaction in the derived starting information, the operator's terminal can be used when determining whether or not restarting is necessary. Processing such as display is possible.
[0035]
In the derived transaction model, online responsiveness is ensured by allowing the occurrence of a situation in which the derived activation transaction is committed and the derived transaction is aborted. Therefore, the ability to strictly manage the restart of the derived transaction contributes to the stability of system operation.
[0036]
In the present invention, it is preferable that the calculation means includes a total amount control unit that restricts activation of the derived transaction in accordance with the total amount of transactions managed by the online response unit and the derived transaction management unit. As a result, the online transaction that requires an online response due to the stay of the derived transaction is not delayed. “Derived transaction activation restriction” is, for example, waiting for the input of an internal business process request among the business process requests to be a derived start transaction, or executing a business process request while This includes a process of canceling the startup, and further causing an error in the execution of the derived startup transaction. Derived transactions whose start has been canceled can be restarted when the system load is reduced, for example, the retention of transactions is reduced.
[0037]
In the derived transaction model, since an incidental business that does not perform an immediate online response is executed as a derived transaction, the derived transaction has a longer time for waiting for execution than the online transaction. For this reason, when the total amount of transactions being executed is large, the total amount control unit performs processing for restricting activation of the derived transaction. This gives priority to the processing of online transactions that require online responses. In the embodiment having the total amount control unit, it is possible to ensure the online responsiveness while performing complicated processing by making the maximum use of the capacity of the system by restricting the activation of the derived transaction that processes this incidental work. it can. Thereby, the daytime processing of batch processing can be realized stably and strictly.
[0038]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings. The present invention has three embodiments. The first embodiment discloses the structure and usage of a derived transaction model. In the second embodiment, a technique for realizing the characteristics of a derived transaction using a lock on a DB is disclosed. The third embodiment discloses a technique for avoiding an exceptional deadlock in the second embodiment.
[0039]
[First Embodiment]
FIG. 1 shows the first embodiment.RutoIt is a block diagram which shows the structure of a transaction control system. In the example shown in FIG.GThe transaction control system includes a receiving
[0040]
The arithmetic means 4 controls the business process request input from the
[0041]
Cash deposits input from the
[0042]
The derived transaction is not requested as a business process request from the terminal, but is requested to start from a program of another transaction. A transaction that requests a start request for a derived transaction in accordance with the execution of the program is referred to as a derived start transaction here. Then, the derivative transaction (T1) activated by the derivative activation transaction may activate another derivative transaction (T2). In this case, the derivative transaction (T1) is a derivative activation transaction.
[0043]
The online transaction performs a process necessary for an online response, determines the necessity of an accompanying process, and requests an activation request for a derived transaction when the accompanying process is necessary. When there is a request for starting a derived transaction, the derived
[0044]
Referring to FIG. 1, the derived
[0045]
Derived activation information is required for starting and managing the derived transaction, such as the data passed from the derived activation transaction, the type of incidental business, the storage location of the derived activation information in the file, and the activation time (entry time) of the derived transaction. Information. A derivation message for executing the derivation transaction is created based on this derivation activation information or each data that is the basis of the derivation activation information. The derived
[0046]
The derived activation information
[0047]
As described above, in this embodiment, the derived activation transaction and the derived transaction are defined as follows.
(1) Individual ACID
Each of the derivative activation transaction and the derivative transaction satisfies the ACID characteristic. The derivative transaction can also activate another derivative transaction as a derivative activation transaction.
(2) Extended seriality
A derived transaction commits only when the derived activation transaction commits. When the derived activation transaction is committed, the operation of the derived transaction may be started.
(3) Expanded atomicity
The abort of the derived transaction does not extend to the derived start transaction.
According to (2) and (3), the nature of one-way atomicity becomes clear. One of the conditions for committing a derived transaction is a commit of a derived start transaction. On the other hand, the derivative activation transaction is committed regardless of the fate of the derivative transaction. Considering a derived usage transaction in which a derived activation transaction and a derived transaction are combined, the derived usage transaction is not atomic. (3) The utility of the extended atomicity is that the derived activation transaction is committed early, the lock is released, and the responsiveness of the derived activation transaction is improved. Derived transactions can be executed in near real time, so processing that was previously performed in batch processing is executed as a derivative transaction with a slight delay in online response, but almost simultaneously with other online transactions. be able to.
(4) Extended isolation
Data handled by the derived activation transaction and the result can be passed to the derived transaction. This depends on how the derived transaction is started. The derived invocation transaction does not wait for the result of the derived transaction. Data passed from the derivative invocation transaction to the derivative transaction is isolated from other transactions. On the other hand, the commit of the derivative activation transaction makes the resource accessible from other transactions including the derivative transaction.
(5) Extended consistency (optional)
Since the derivative activation transaction satisfies the ACID characteristic, the contents of the database and the like are in a consistent state for the application by the transaction. However, in the derived transaction model, this consistency is system level consistency and need not be business level consistency. In other words, in the derived transaction model, consistency at the business level may be ensured by executing a derived transaction that processes the accompanying business. An example of using a derived transaction is data that records intermediate data at the business level in a durable state so that consistency lost at the business level is strictly consistent at the system level. A structure can be used. For example, if there is data necessary for online response to the terminal and data that should be organized or optimized after several seconds or the next day as a result of processing the online transaction, the derivative activation transaction is Data necessary for online response is updated, and data required by the next day is stored with durability as intermediate data lacking consistency at the business level. The derivative activation transaction is committed at the stage when the intermediate data is stored. Data that needs to be organized by the next day can be processed after the online response is completed using a derived transaction.
[0048]
FIG. 2 is an explanatory diagram for explaining the nature of the derived transaction, and FIG. 2A is a diagram illustrating an example in which a derived transaction activation request is made from the derived activated transaction. As shown in FIG. 2A, when there is a business process request, the online transaction is executed as a derivative activation transaction S1, and after committing the derivative transaction to the derivative activation request, commit C1. Thereafter, the derived transaction S2 is executed and the commit C2 is performed.
[0049]
A method for managing a derived transaction using an online transaction control system includes a step (S1A, online response unit 10) of executing a business process request input from a terminal or the like as an online transaction, and a part of the online transaction execution process. A step (S1B, derived activation information storage control function 22) of storing the derived activation information necessary to activate the derived transaction in the
[0050]
FIG. 2B is a diagram illustrating a case where the derivative activation transaction is a linked transaction. A mechanism for executing a plurality of tasks in one transaction is referred to as linkage here. Since the linked activation task S3A and the linked passive task S3B are executed as one transaction, the atomicity of whether or not both are successful is guaranteed. Taking the accounting system as an example, the linked startup service S3A is, for example, a deduction of electricity charges, and in this case, the linked passive service S3B is a withdrawal from the ordinary deposit. Since the interlocking transaction is executed as one transaction, the electricity fee is successfully paid, but an inconsistent state in which the amount is not withdrawn from the ordinary deposit does not occur. In the example shown in FIG. 2B, the linked startup service S3A requests the linked passive service S3B to withdraw the ordinary deposit. When the linked passive service S3B makes a withdrawal, the process is returned to the linked startup service S3A. Upon receiving the interlock return, the interlock activation work S3A commits after performing other processing. Then, when there is a change in the account balance of the ordinary deposit and there is an accompanying task that does not require an immediate online response, the linked passive task S3B starts the derivative transaction S4.
[0051]
FIG. 2C is a diagram illustrating an example in which a derived transaction requests activation as a derived transaction. In the present embodiment, the derived transaction itself can be a derived start transaction. The derived transaction can also start the derived start transaction as a derived transaction. In the example illustrated in FIG. 2, when a derived transaction aborts after the derived activation transaction is committed, the derived transaction is restarted based on the derived activation information. By using the modes shown in FIG. 2 in combination, business processing having various characteristics can be realized.
[0052]
The configuration shown in FIG. 1 and the mechanism shown in FIG. 2 can be realized by executing a predetermined program by the calculation means. The calculation means 4 includes a CPU that performs various calculations according to a predetermined program (command). The CPU schedules (routes) an online transaction according to a business process request (message), and controls online transactions such as a command for returning the execution result to the
[0053]
like thisNatoTransaction systemGopuThe program includes a command for operating a CPU (calculation means). For example,GTransaction systemGopuThe program is required to start a derived transaction when a command to execute a business process request input from a terminal or the like is executed as an online transaction, and when a start of a derived transaction is requested as part of the execution process of this online transaction. A command for storing the derived activation information in the file, a command for committing the online transaction that started the derived transaction without waiting for the execution start or commit of the derived transaction, and, if the online transaction aborts, And a command for controlling not to start or commit. The calculation means 4 operates as the derivative
[0054]
GTransaction systemGopuThe program is stored in a
[0055]
For a program, when the “command for operating the CPU (calculation means)” is referred to, the CPU depends on other commands such as an operating system stored in advance in the program storage unit and a command for operating the CPU only with each command. And / or a command for operating the. Here, “operating system” is interpreted broadly. Includes transaction manager and database manager. Therefore, IMS, FP, SAIL, and the like are also considered OS for convenience.
[0056]
The derived activation information storage control command may be only a command for handing over the storage location of the derived activation information to the operating system. In this way,TheTransaction systemGopuIn the
[0057]
The description regarding this program, system or method, carrier medium, etc. is the same in the embodiments described later. In particular, the same applies to each embodiment in that each of the functions, processes, and commands to which the same name is assigned corresponds. For example,GTransaction systemGopuIn order to realize the derived activation information storage control function, the program includes a derived activation information storage control command for realizing the function.
[0058]
Next, how to use the derived transaction in the online system will be described. FIG. 3A is an explanatory diagram for explaining a terminal response or the like according to the usage of the derived transaction. The terminal 1 (1A or 1B) inputs a business process request to the
[0059]
Taking an account system as an example, the usage shown in FIG. 3A is a name identification process when an account is newly established. When adopting an account system with a customer as a unit in the account system, if a customer who has an account at the sales office 201 newly establishes an account at the sales office 202, a name identification process for associating these two accounts is performed. The name identification process is performed when, for example, the same name and address are the same. For this reason, when a new account is opened, an account having the same name as that account name must be searched from all accounts of all sales offices. The opening of the account itself can be completed without performing the name identification process. For this reason, the account opening process is constructed as an online transaction, and the name identification process is constructed as an incidental operation of the account opening process. This makes it possible to perform name identification processing without using batch processing while committing account opening early.
[0060]
As another utilization method shown in FIG. 3A, there is a process of performing data duplication according to the application. For example, it is assumed that information relating to a loan is stored in the loan master DB in units of loan destination numbers that are serial numbers of all sales offices. In the loan master DB, a reservation segment is created with a loan destination number as a unit by a reservation operation that specifies a scheduled execution date of the loan. If the approval of the headquarters is required for the execution of the loan, a request for approval is prepared by the approval request preparation operation and sent to the headquarters. At the headquarters, operations for approval or disapproval are made according to the contents of the loan. At the branch office, the loan execution operation is performed together with the case approved by the headquarters on the scheduled loan execution date, and credited to the account of the loan destination that can be specified by the loan destination number.
In order to perform the loan execution operation at the branch, it is necessary to inquire a list of projects that should be executed on that day. However, when making an inquiry from the loan master database, the loan destination number is taken not by store but by all store serial numbers. Therefore, it is necessary to search all the lenders, and in this case, processing time in units of minutes is required. Therefore, the reservation segment and the like are duplicated by constructing a decision DB separate from the loan master DB for inquiries at the branch office. The deliberation DB has a data structure that holds reservation segments in order of execution dates for each store number, so that inquiries by store can be made in a short time. Registration of reserved segments in the appraisal DB is completed in a short time because there are many segments under the store number, and the location to be added depends on the scheduled execution date and is not always the final position. Do not mean. On the other hand, the reservation operation, which is the main business, should be completed in a short time. For this reason, in this embodiment, the reservation operation or the like is the main business. Then, the registration of the reserved segment in the approval database is executed as a subsidiary transaction in a derived transaction. In the example shown in FIG. 3A, a reservation operation for registering a reservation segment in the loan master DB is executed in step S11, and an accompanying task is started as a derived transaction S12. The derivative startup transaction S11 that executes the reservation operation commits without waiting for the accompanying task S12 to commit. Thereby, the reservation operation is completed in a short time. In the incidental task S12, the reservation segment is registered in the deliberation DB a little later than the reservation operation.
[0061]
FIG. 3B is an explanatory diagram illustrating an example in which cancel / recut main is executed in the earlier date completion processing system as an accompanying task. The earlier date completion processing system is a technique for processing settlement such as account transfer, which has conventionally been performed by batch processing, as an online transaction during the day, and details thereof have been separately filed by the same applicant. Here, the outline will be described. Account processing such as account transfer has a bill date. In the future date completion processing system, account processing on the account date after the next business day (destination date) is executed based on the current balance, and the balance on that account date is calculated. For this reason, the future date completion processing system holds the balance of the calculation date and the balance of the future account date.
For example, if there is a balance of 30,000 on the 10th and the electric charge is deducted 10,000 on the 10th and the 11th is the account date, the balance on the 10th is 30,000, The balance of the previous date) is 20,000. When there is an account processing request (business processing request) such as cash withdrawal on the 10th, the balance of 30,000, which is the 10th, is referred to. On the other hand, when the date is changed, the balance on the 11th is referred to. The balance on the 11th is a balance for which the electricity charges have already been withdrawn, so there is no need to perform any processing when changing the date. For this reason, the processing for completing the future date is completed when the account transfer or the like is processed on the previous date.
[0062]
Now, after processing the deduction of electricity charges on the previous date, it is assumed that there is a change in the account balance on the 10th. For example, suppose there are 25,000 withdrawals. Since the balance on the 10th is 30,000, withdrawal can be made, and after the withdrawal, it becomes 5,000. For the balance on the 11th, subtracting 25,000 from 20,000 yields minus 5,000. The balance becomes negative unless it is based on a contract such as an automatic loan, so the balance of the 11th is insufficient and the withdrawal of electricity charges must be cancelled. If the withdrawal of electricity charges is cancelled, the balance on the 11th will be 5,000. Then, if there is an unsettled electricity charge, for example, if there are 6,000 deposits with the 10th as the account date, the balance on the 11th will be 11,000 and the electricity charge can be withdrawn. It becomes. In this case, the deduction of the electric charge is re-executed (recut) in accordance with a contract for transferring the electric charge from the balance of the account date.
[0063]
In this way, in the future date completion process, settlement of the future date is executed when the account balance is the final balance. If there is a change in the account, the settlement of the future date is adjusted again. Thereby, night batches of settlement such as account transfer can be processed during the day. This intraday processing of fund transfer is also referred to as center batch processing here. The center batch process is not a batch process but an online process started by a command input from the
[0064]
If a change in the account balance of the current day due to an online transaction and the cancellation and recutting caused by this change are executed in one transaction, various adverse effects occur. First, since the execution time of one transaction becomes long, online responsiveness deteriorates. Secondly, since the number of account processing requests to be canceled or recut cannot be predicted, there is a possibility that the processing cannot actually be performed due to, for example, a limit on the number of linkages. For this reason, it is desirable to adopt a derived transaction model in the completion process for the future date.
[0065]
As mentioned above, the derived transaction model can use extended consistency. Since the derivative activation transaction satisfies the ACID characteristic, the contents of the database and the like are in a consistent state for the application by the transaction. However, this consistency is system level consistency and need not be business level consistency.
[0066]
Data lacking in consistency at the business level has, for example, a data structure that allows a minus of the possible withdrawal amount at the previous date. The state in which the amount that can be withdrawn is negative can be eliminated by the end of the negative account date (in fact, the negative state is resolved within a few seconds by the derivative transaction). FIG. 3B shows how to use the derived transaction model in the completion process for the previous date. In the above example, if there is a withdrawal request of 25,000 on the 10th, the main business (online transaction) S17A makes a withdrawal of 25,000 with reference to the balance on the 10th, Update the daily balance. The balance on the 11th will be minus 5,000. Since the account balance has changed, the cancel / recut main is activated as a derived transaction. If minus 5,000 is stored in the file and the cancel / recut main S18A is activated as a derived transaction, the main process S17A commits and completes the withdrawal process because the subsequent process is irrelevant to the online response. That is, the cash withdrawal process is committed without waiting for the completion of the cancel / recut main. The re-adjustment of settlement of the previous date is processed in the derivative transaction as an incidental operation to the main operation of changing the account balance.
[0067]
In the cancellation / recut main S18A, the account processing to be canceled is specified based on the balance of minus 5,000 on the 11th. If the account processing established on the 11th is only the deduction of electricity charges, the cancellation / recut main (derivative T) activates the cancellation of the electricity charges as a derived transaction. In step S17B, the electricity charge withdrawal is canceled and the balance on the 11th is updated. In the cancellation process S17B of the electric charge withdrawal, the cancellation / recut main S18B is activated again as a derived transaction because the account has been changed. The cancellation / recut main S18B determines that there is no cancellation target because the account balance on the 11th is positive, and the processing is completed because there is no unsettled transaction.
[0068]
In the future date completion processing system, a derived transaction model is adopted, and the account processing request on the current day is processed as an online transaction, and a derived transaction is used for the adjustment of the account processing of the future date accompanying the account transfer. Thus, daytime processing such as account transfer is realized while ensuring good online responsiveness. This future date completion processing system performs cancellation / recutting in accordance with the priority order between account processing by utilizing the fact that the settlement of the future date has no settlement completion (can be canceled until the account date is reached). Thus, the account processing can be rearranged according to the priority order.
[0069]
FIG. 4 is an explanatory diagram showing a configuration of a cancel / recut main that performs replacement of account processing according to priority. The details of the technology shown in FIG. 4 are described in the specification and drawings of “Advance Date Completion Processing System and Method” of Japanese Patent Application No. 2001-078306 by the same applicant. Here, the outline will be described. Referring to FIG. 3, the cancel / recut main activates the main business, and the main business activates the cancel / recut main. This process by repeatedly starting the derived transaction is called a spiral process. Since each cancel / recut main S18A, S18B is an independent transaction satisfying the ACID characteristic, it is not possible to realize continuous processing by repetition using internal information. For this reason, in the spiral process, the derivation management flag for maintaining the continuity of the determination of the cancel / recut main and the process is used.
[0070]
Referring to FIG. 4, the derivative activation transaction uses a linked transaction as shown in FIG. In the linked activation process, the account process is canceled or recut. In conjunction with the cancellation of this account processing, the linked passive processing side deposits and withdraws to the ordinary deposit. For example, in S31, the withdrawal of the electricity charge is canceled, and the fact that payment is not possible is stored in the DB that manages the automatic transfer. In the linked passive processing, the amount of cancellation is credited to the balance of the ordinary deposit on the account date. Since the cancellation of the electricity charge is linked to the cancellation amount deposit to the ordinary deposit, it is executed as one transaction. Therefore, cancellation and deposit are atomic. The linked activation process S31 and the linked passive process S32 reach the synchronization point when the linked passive process is established and the process corresponding to the establishment is completed on the activation process side (C35).
[0071]
Cancel re-cut main refers to segments such as derivation management flags, balance details of future dates that allowed negatives, transaction details that record successful transactions, and remaining shortage details that record unsettled transactions, Determining what processing should be performed to optimize the account (or restoring consistency as a business), and in accordance with the result of the determination, cancel processing, modified recut processing, and recut processing are derived transactions. Start as. The cancellation / recut main first determines whether the possible withdrawal amount is negative on the account date of the previous date. If it is negative (branch B1), cancellation processing for canceling the account processing request with the lowest priority on the negative accounting date is started as a derived transaction. When the cancel process is derived and activated, the cancel / recut main reaches the synchronization point (C31) and ends.
[0072]
After the cancellation is performed by interlocking the interlocking activation process S31 and the interlocking passive process S32, and the account balance is updated for the canceled amount, the cancellation recut main checks the possible withdrawal amount again. The cancellation processing of the account processing request having the lowest priority at the time is derived and activated, and then committed (C31). This repetition of the cancellation process is referred to herein as cancellation spiral SP1. The cancellation spiral SP1 ends when the withdrawal possible amount is gone (branch B2).
[0073]
When the account balance is increased or the minus of the withdrawal possible amount disappears (branch B2), it is determined whether correction recutting is possible. The correction recut is a process in which the account processing to be established on the account date is changed to a predetermined priority order by replacing established account processing and unestablished account processing for the account date of the previous date. It is. Specifically, the account processing request with the highest priority among the account processing requests that have not yet been established is used as the highest-level account processing request, and is used for account processing requests that are established with lower priority than this account processing request. The total withdrawal amount is summed, and the balance is added to calculate the corrected withdrawal amount. If the highest level account processing request is smaller than the corrected withdrawal possible amount (branch B3), correction recutting of the highest level account processing request is executed (S34). When the correction recut is executed, the balance of the account date becomes negative. Therefore, in the next cancellation / recut main that is activated, the account processing requests that have been established are canceled in ascending order of priority until the possible withdrawal amount becomes positive.
[0074]
When the correction recut is repeated, the priority order of the account processing requests stored in the transaction details becomes higher than the priority order of the account processing requests stored in the remaining shortage details. In this state, it becomes impossible to calculate the corrected withdrawal possible amount, and therefore it is determined that the correction recut is unnecessary (branch B4).
[0075]
Account processing requests that cannot be modified and recut will not be recut. In the recut determination, recutting of account processing requests that are not subject to correction recutting is considered. For example, because re-cutting is premised on cancellation, re-cutting of account processing requests on the day when account processing is not canceled, or re-cutting of low-priority account processing requests determined not to be corrected / re-cut Determine whether or not. The re-cut is the transaction amount (withdrawal amount) of the highest priority account processing request and the sunrise of the target account among the unsettled account processing requests whose accounting date is the processing date (for example, the calculation date). Compare the possible amount of money. If the transaction amount is smaller than the possible withdrawal amount, recutting is possible, so recut of the account processing request is started as a derived transaction and committed (C33).
[0076]
The interlock activation process S37 and the interlock passive process S38 perform a recut process in conjunction with each other, and after reaching the synchronization point, the cancel / recut main is activated again. If there is no minus in the possible withdrawal amount, the correction recut is completed, and there is no recut target, the cancel recut main completes the process. Generally, when the balance decreases, the cancellation spiral SP1 operates, and when the balance increases, the modified recut and recut spiral SP2 operate. Cancellation re-cut main uses derivative transactions to sequentially perform optimization of account processing, so that it is possible to strictly execute the future date completion process assuming that cancellation occurs at the future date, It is possible to stably realize a complicated process of settlement based on priority, and because it is a process for completing the previous date, it is possible to perform continuous operation for 24 hours while performing a process based on the priority. Furthermore, since the cancellation / recut main performs optimization based on the priority of the account processing request every time the account balance changes, the order of execution of the account processing requests is limited compared to batch processing. Disappears.
[0077]
This sort of account processing and nighttime daytime processing using the previous date can be used in various online systems regardless of the accounting system. For example, the priority order for reservation of tickets and accommodation facilities is reflected, the selling price or product is changed when the product is sold via the Internet or the like, and various information is updated when there is an order. Further, in a system in which sales, inventory management, demand prediction, and ordering are associated with each other, the online transaction that links sales and inventory management is executed, and processing necessary for ordering is started as a derivative transaction. Since the presence or absence of an order is irrelevant to sales, the online transaction is committed when sales are recorded with reference to inventory. The derived transaction determines whether or not there is an order according to the number of stocks and the demand forecast. In this case, sales and inventory management are business processes (main business), and ordering is an auxiliary process (accompanying business). Also, depending on the establishment of sales, arrangements for delivery and billing are required. Delivery and billing arrangements triggered by sales can also be triggered by derivative transactions. As described above, when the responsiveness, the automation of complicated processing, and the strictness of processing should be simultaneously achieved in the online system, the derived transaction model according to the present embodiment can be used.
[0078]
When the derived transaction model according to the present embodiment is used and intermediate data regarding business consistency is generated by execution of the derived start transaction, the intermediate data is stored in the
[0079]
FIG. 5 is an explanatory diagram showing an example in which a derived transaction is used for the terminal return continuous processing. Derived transactions are used to process accompanying business. As a special example of the incidental work, there is terminal wrapping continuous processing. The terminal wrapping continuous process is related to a process that is not completed unless the process of a transaction input from the terminal repeats data transmission / reception with the terminal due to various restrictions of the system. When data is transmitted / received to / from the terminal, since the communication speed is generally slower than the calculation speed, the CPU has to wait for communication.
[0080]
For example, in the periodic withdrawal process, the number of items to be paid may increase, such as 120 items for 10 years in a month. In this case, since the system resources are limited, not all details can be processed in one transaction. Therefore, for example, 5 transactions are processed in one transaction. A dummy response is transmitted to the terminal every time processing of 5 specifications is completed, and when the continuation processing request is received from the terminal, the processing of 5 specifications is repeated. However, since data transmission / reception between the terminal and the host generally requires about 2 seconds, for example, processing for 100 items requires 40 seconds (2 seconds × 20 times). The time required for the CPU to process 5 specifications is about 0.1 seconds excluding message transmission / reception.
[0081]
For this reason, in the example shown in FIG. 5, when a business process request that is a terminal wrapping continuous process is a main business, the calculation of payment contents including interest is considered as an incidental business, and repeated derivative transactions are used. Therefore, the deterioration of the response due to the communication with the terminal is prevented. That is, in the terminal return continuous processing, the accompanying business side performs the actual processing, and the main business is responsible for the terminal response. In the example shown in FIG. 5, when receiving a funding periodic withdrawal request, the main business S13A specifies the details to be paid and performs the first five payment processing. Then, the main business S13A registers the payment details including the interest in the transaction details of the
[0082]
The payment process S14A performs the payment process for five items based on the key of the item to be paid given from the main business S13A. Payment details including interest are recorded in the transaction details and updated. And payment processing S14B which performs the same processing is started. In step S14B, similarly to step S14A, the payment process for the next five items is performed based on the key of the item to be paid passed from payment process S14A. This is repeated, and when the payment process is completed in the payment process S15, the processing flag in the
[0083]
The payment process is repeatedly invoked as a derived transaction having ACID characteristics. Apart from this, when the status confirmation is received from the terminal, the main task S13B checks the terminal control DB7. If the processing flag in the
[0084]
As described above, in the terminal return continuous processing, the transaction execution unit 16 starts the derived transaction when the main business transaction that processes the business processing request starts (S13A), and the derived transaction repeatedly starts the derived transaction until there is no processing target. (S14A, S14B, S14C, S14D, S15). On the other hand, the main business transaction repeats a dummy response to the terminal until the processing is completed by the repeated activation of the derived transaction (step S13B). After the process to be processed is completed by repeatedly starting the derived transaction (payment process), the main business transaction returns a response to the terminal.
[0085]
In the example shown in FIG. 5, for example, the derived transaction is executed 19 times in 100 specifications, and the required time is 1.9 seconds (0.1 seconds × 19 times). All payment processes are completed within 2 seconds until the (status confirmation) is received, and the overall response time is 4 seconds. This is 1/10 of the response to the terminal.
[0086]
In addition, when a large number of continuous processes are performed, the operation can be simplified by using a derived transaction, and the overall processing speed can be improved. For example, in order to actually execute a certain process, there is a task that requires the approval of an administrator. For example, it is assumed that the manager's approval is required for the currency transfer process. In this case, the contents of the processing are registered in the message DB, and actual transfer is performed at the stage where the administrator's approval is obtained. When notification of approval is obtained individually, operations for the number of transfers and data transmission / reception with the terminal are required. On the other hand, if it is attempted to execute all the transfers in one transaction, the processing time becomes long, and there is a possibility that a shortage of system resources may occur. For this reason, a derived transaction is used.
[0087]
When receiving the transfer request form from the customer, the operator performs the transfer content registration operation based on the transfer request form. At this point, no actual transfer is performed. The contents of the transfer contents registration are printed on the slip. When the number of registered transfer contents is gathered to some extent, the operator requests the manager's approval. The administrator confirms that the transfer request form matches the printed content of the slip, and checks the slip. When the slip is checked, the operator performs an approval notification process. The transfer process is executed by this approval notification process. The approval notification process processes up to 22 transfers in one operation by inputting the first message number and the number of cases.
[0088]
In the approval notification process, first, as an online transaction, the message DB is read with the first input message number, and if it is valid, the deposit process is performed, then the next message number is set, and the approval notification process is derived transaction. Start as. In the derived transaction, the same processing is performed based on the message number passed from the preprocessing, the next message number is set, and the derived transaction is started. By repeating the derivation transaction as shown in FIG. 2C until the input number is reached, a maximum of 22 transactions are executed in one operation. Thereby, the system load can be reduced while omitting the terminal response.
[0089]
In this way, in this embodiment, the following two ways of using “derived transactions”:To disclose. (1) An online transaction is directly requested, and it is not necessary to respond at the time of online, but a business process that must be processed according to the processing result of the online transaction is processed as a derived transaction. This (1) ensures online responsiveness by executing processing that has been conventionally performed in batch processing, or processing required by bringing batch processing online, as a derived transaction. (2) In order to reduce the communication time between the terminal and the CPU, the main business is processed by repeating the derived transaction without processing the online response itself. This (2) corresponds to a terminal return continuous process, an approval notification process, and the like.
[0090]
Next, a method for limiting the execution of a derived transaction according to the CPU load in the derived transaction model will be described. Derived transactions do not need to be executed in synchrony with derived initiating transactions. For this reason, it is possible to commit only an online transaction that is a derivative activation transaction, while canceling execution of the derivative transaction. When the execution of the derived transaction is stopped, the load on the CPU is reduced and the responsiveness of the online processing can be maintained well. The canceled derived transaction may be restarted in a state where the load on the CPU is reduced. Furthermore, there is a possibility that a derived transaction such as a center batch process may be activated, and an internal process may be interrupted when the CPU load is high. As described above, in this embodiment, a complicated job is executed while preventing a situation in which the online response is deteriorated due to the accompanying job.
[0091]
Referring again to FIG. 1, the computing means 4 includes a total
[0092]
In this example, the total
[0093]
In the example shown in FIG. 1, the total amount is controlled based on the number of transactions (request messages for business processing requests) waiting to be executed. The number of business process requests is, for example, the number of request messages stored in a queue. Here, two-stage control is performed: a first level that prompts a decrease in the activation of the derived transaction and a second level that immediately stops the derivative activation. When the number of waiting transactions exceeds the first level, the derivative activation transaction input
[0094]
FIG. 6 is a flowchart showing a configuration of a total amount control process for performing two-step total amount control. Here, it is assumed that the first level <the second level. First, the stay or execution status of a transaction is investigated (step S41). If the total number of transactions stored in the queue or the like exceeds the first level, the input of the derivative activation transaction is interrupted (step S42). Further, when there is a stay exceeding the second level, the start of a new derived transaction by the currently executed derivative start transaction is stopped. This may be done by not storing the derivative activation message after storing the derivative activation information in the
[0095]
On the other hand, if the number of business process requests registered in the queue is less than the first level (step S46), if the suspension and suspension related to the derived transaction are ongoing (step S47), is the staying
[0096]
In the present embodiment, even when the activation of the derived transaction is stopped, the restart is managed based on the derived activation information stored in the
[0097]
As described above, according to the present embodiment, by utilizing the derived transaction model, the derived start transaction is committed early, and even if the derived transaction is aborted, it is possible to control the restart reliably. Therefore, it is possible to provide complex processing while maintaining a good online response. In addition, when total amount control is performed, the number of executions of derived transactions is limited according to the CPU's ability, and it is indirectly online. Transaction responsiveness can be ensured. Thereby, for example, work that has been conventionally performed by nighttime batch processing can be reconstructed into daytime processing. In most aspects, derived transactions are capable of processing that is infinitely close to online real-time. For example, taking an account system as an example, it is assumed that payment is made at an ATM when there is a shortage and an unsettled account process. Since the deposit process is a derivative activation transaction, commit early and deposit the balance by deposit in the book. While performing this passbook entry, the re-cutting of the unsettled account processing by the derived transaction is completed. For this reason, the balance after recutting can be continuously printed on the passbook.
[0098]
In this way, the derived transaction is normally processed in a state close to online real time, whereas on the other hand, when the processing becomes exceptionally long or when the CPU load is large, it is processed after several tens of seconds. Even if there is a problem with the incidental application, it is possible to correct the application while completing the online response and re-execute only the incidental action afterwards. In this way, in the derived transaction model, the programmer and system can be freed from the harmful effects of performing a large number of processes in one transaction, and in particular, the complicated transaction process that tends to be abandoned in the normal transaction model. System development is possible.
[0099]
Second Embodiment
As disclosed in the first embodiment, the derived transaction model provides excellent harmony between online responsiveness and implementation of complex business processing. However, since the derived transaction model and the chained transaction model are not standardized, the mechanism is not provided depending on the transaction management system (TP monitor, transaction manager) to be used. However, the characteristics of the derived transaction can be ensured by using a lock mechanism for the DB. In the second embodiment, an example in which two databases are used to manage the characteristics of the derived transaction is disclosed. By applying the second embodiment, it is possible to manage the ACID characteristics of normal transactions. In other words, a derivative transaction model can be constructed if the system can ensure seriality by locking the DB. There are various reasons why this second embodiment uses two databases, one of which is to eliminate the need for reorganization processing of these two DBs. Therefore, even if two DBs are used, the system management load does not increase.
[0100]
<Derived transaction management>
FIG. 7 shows the accounting system according to this embodiment.RutoTransactioncontrolIt is a block diagram which shows the outline | summary of a structure of a system (or online system).Transaction controlThe system includes a receiving
[0101]
The
[0102]
In addition, the
[0103]
Deposit / withdrawal requests are input to the CPU via the
[0104]
The
[0105]
The
[0106]
In addition, the transfer of public utility charges (external self-vibration) is brought into the carry-in
[0107]
In the example shown in FIG. 7, the
In the present embodiment, the derivative activation information is stored in the
[0108]
The derivative activation transaction stores derivative activation information. However, if the derivative activation transaction is aborted, it is assumed that the derivative activation information has not been updated due to the rollback. Therefore, the derivative transaction can know whether the derivative activation transaction has been committed or aborted by reading the derivative activation information immediately after the activation is started. For example, in an example in which the in-use flag is included in the derived activation information, if the derived activation transaction is committed, the in-use flag is “in use” (for example, “1” for a character). On the other hand, when aborted, even if the in-use flag is updated to “in use” by the derivative activation transaction, the update is rolled back. For this reason, the derived transaction can be determined that the derived activation transaction has been aborted when the in-use flag of the derived activation information is “available” (for example, “0” of the character). Thus, the condition that the derived transaction commits only when the derived activation transaction commits can be satisfied.
[0109]
The derived transaction is requested to be activated during execution of the derived activation transaction. Therefore, before the derivative activation transaction is committed, the derivative transaction may be scheduled to start processing. In order to prevent this, the derived transaction goes to read the derived activation information immediately after its start. Since the derived activation information is locked until the derived activation transaction is committed, the derived transaction waits until the lock is released. That is, the derivative transaction reads the derivative activation information at the start thereof, and waits for the commit of the derivative activation transaction. As a result, the seriality between the derived activation transaction and the derived transaction is managed.
[0110]
In this way, the derived activation information stores the derived activation information as a part thereof, and the derived transaction reads the derived activation information at the start of processing, thereby realizing the characteristic of the derived transaction called extended seriality. .
[0111]
The
[0112]
In the example shown in FIG. 7, the
[0113]
The computing means 4 processes an online processing request input from the terminal or the like as an online transaction and outputs the processing result as a response to the terminal, and the online response or the predetermined derivation. A transaction management unit 64 manages a derived transaction requested to be activated as part of the transaction execution process and manages the online transaction.
[0114]
In the present embodiment, in particular, the transaction management unit 64 refers to the derived index DB, and derives the derivative management serial
[0115]
The derivation management serial
[0116]
The derived activation information
[0117]
The derivative activation transaction commit
[0118]
The derivation transaction commit
[0119]
The derivative
[0120]
FIG. 8 is an explanatory diagram showing the relationship between a JOB and a derived index DB. CICS and IMS, which are types of TP monitors, provide an abstraction called a region. A region is an address space where a plurality of processes can be executed. A region is a unit that possesses resources, and failures at the time of application execution are localized in the region. Business processing requests are scheduled in the region. For example, when 50 regions are activated, transactions with
[0121]
In the example shown in FIG. 8, the derivative activation transaction is executed with any JOB number in a predetermined JOB number group. The derived index DB has an
[0122]
In the example in which the index information is a bitmap, whether the derivation management serial number is in use is indicated by the bit ON (1), OFF (0), and the derivation management serial number is specified by the position of the bit. Here, as an example, 400 derivative management serial numbers that can be used from one region are assumed to be 400. In this case, the bitmap has 400 bits. That is, the length is 50 when the unit is 1 byte. Taking
[0123]
For example, the derivation management serial
[0124]
Thus, in a preferred embodiment, the derivation management serial
[0125]
FIG. 9 is an explanatory diagram illustrating data items of the derived DB in this case, and FIG. 9A is a diagram illustrating an example of items of the derived index DB. For example, N is 125 and M is 400. The derived
[0126]
FIG. 9B is a diagram showing an example of items in the derivation management DB. The derivation management DB has a derivation management serial number as a key value. The other items are details of the derived activation information. By holding the APPL ID of the derived activation transaction and the APPL ID of the derived transaction, it is recorded which main business has derived and started which associated business. The derived edit number is used to specify the input / output format. The entry date and time are used to search for aborted derived transactions. The busy flag is used by the derived transaction to know whether or not the derived start transaction has been committed. The FIFO storage is a storage area for various data contents prepared for the derivative activation transaction to activate the derivative transaction.
[0127]
In this specification, the term “FIFO” means a formatted input / output information area. It is not used as an abbreviation for first-in first-out. FIFO is an abstraction provided by SAIL, an IMS / ESA online application development / operation support program. All inputs from the terminal or the like are edited and set in an information area called FIFO according to the business. For this reason, the application program can be developed on the premise that data of a specific item is set at a previously defined position in the FIFO, regardless of the input format from the terminal or the like. That is, by using the FIFO, an application program can be developed regardless of the format of the input / output message. The input / output message and the FIFO are related using the edit definition. For example, when a derivative activation transaction activates a derivative transaction, data necessary for executing the derivative transaction is set in the FIFO, and a derivative activation request is made. The SAIL then generates a derived message from the FIFO according to the derived edit number. The edit definition for each business is also used for the input of the business process request from the terminal and the output message to the terminal.
[0128]
FIG. 10 is an explanatory diagram illustrating the relationship among the JOB number, the index area number 88 of the
[0129]
As shown in FIGS. 10C and 10D, when the number M of derivation management serial numbers specified by one index bitmap is determined, the derivation management serial number is based on the index area number 88 and the bit position. Can be specified.
[0130]
FIG. 11 is a flowchart illustrating an example of a derivation request management process for managing derivation transaction requests. FIG. 12 is a flowchart illustrating an example of a derived characteristic management process for managing the characteristics of a derived transaction. The derivation request common process shown in FIG. 11 is executed as a part of the derivation activation transaction. The derived characteristic management common process shown in FIG. 12 is executed as a part of the derived transaction or as another process.
[0131]
Referring to FIG. 11, when a derived activation request is received from a derived activation transaction, the derived request common process first reads the derived index DB using the JOB number (that is, the index area number) as a key value (step S52). Then, the remaining number field with the index area number is checked (step S52), and if there is a space, the bit position of the space (index bit is 0) is specified from the index bitmap. If there is no free space in step S52, the spare derived index DB is read and the remaining number field is checked (step S62). If the spare derivative management serial number is in use, the process ends abnormally.
[0132]
When an empty derivative index bit is specified, a derivative management serial number is calculated based on the bit position. Then, this derivative management serial number is set in the FIFO of the region where the derivative activation transaction is operating. Further, the derivation index bit is updated to “1” indicating ON (the corresponding derivation management serial number is in use) (step S54).
[0133]
Subsequently, the derivation management DB is read using the derivation management serial number as a key value (step S55), and the remaining number field and the derivation number field of the
[0134]
FIG. 12 is a flowchart showing processing at the start and end of a derived transaction. In the derivation characteristic management common processing, when a derivation transaction is scheduled in any region, first, the
[0135]
When the derivation transaction succeeds in reading the contents of the derivation management DB, first, the derivation transaction checks the in-use flag. The in-use flag is updated to 1 indicating in-use in step S57 by the derivative activation transaction. If the derivative startup transaction commits, this in-use flag remains “in use”. On the other hand, when the derived activation transaction aborts after step S58, the update to the “in use” flag by the derivative activation transaction is canceled by rollback, and the in-use flag is 0 indicating that it can be used. . Therefore, in step S72, if the in-use flag is enabled, the derived transaction is terminated only when the derived start transaction is committed, and the derived transaction is terminated without executing the application program according to the property of the derived transaction. (Step S74).
[0136]
If the derived activation transaction has been committed successfully, the in-use flag is “in use”, so the application program for the derived transaction is called to control execution (step S75). When the execution of the application program is completed, the derivation management DB is read with the derivation management serial number as a key in the derivation characteristic management common processing (step S76). Then, the in-use flag is updated to be usable (step S77). At this time, the derived index bit of the derived index DB remains in use. Therefore, the derived index bit of the derived
[0137]
Further, when a derived transaction whose characteristics are managed by the derived characteristic management common process shown in FIG. 12 starts another derived transaction, the process shown in FIG. 11 is executed before the derived transaction is committed. .
[0138]
Here, the relationship between each function shown in FIG. 7 and each process shown in FIGS. 11 and 12 will be described. The
[0139]
For example, the program causes the index information of the derived index DB to be specified when there is a request for starting a derived transaction from a derived start transaction that is an online transaction or a derived transaction, and the derivation management is performed based on the specified index information. A derivation management serial number specifying command for specifying a derivation management serial number that can be used for a DB is provided. When this command is executed, the CPU operates as the derivative management serial
[0140]
Further, the program stores the derivative activation information related to the request for starting the derivative transaction by the derivative activation transaction in the segment of the derivative management serial number specified in accordance with the derivative management serial number specifying command, and after storing the derivative activation information. A derivative activation information storage control command for activating the derivative transaction is provided. The CPU operates as the derivative activation
[0141]
The program further includes a derivative activation transaction commit processing command for committing the derivative activation transaction when each process of the derivative activation transaction is normally terminated after the derivative activation information is stored. As a result, the CPU operates as the derivative activation transaction commit
[0142]
In addition, the program includes a seriality control command for starting each process of the derived transaction when the normal read in the state where the derived activation information can be locked is successful at the start of the derived transaction. In the example shown in FIG. 12, this realizes the control of the seriality by the derived activation information reading step S71 in step S12. The CPU that executes the seriality control command performs steps S71 to S75 shown in FIG.
[0143]
The derived transaction management program further updates the derived index DB and the derived management DB to be usable with respect to the derived management serial number used when each process of the derived transaction is normally completed, and the derived transaction commit that commits the derived transaction. Processing instructions are provided. The CPU that executes this command performs the processes of S76, S77, S78, and S79 shown in FIG. In the third embodiment, in order to prevent the occurrence of deadlock, the derived index DB is updated in S78 and S79 as a transaction different from the derived transaction.
[0144]
The program also includes a derivative restart control command for controlling restart based on the derivative activation information stored in the derivative management DB when the derivative transaction is aborted. The CPU that executes this derivative restart control command functions as the derivative
[0145]
As described above, in the example shown in FIGS. 11 and 12, the derived
[0146]
Furthermore, when the derivative management serial
[0147]
In this way, by using contention activation information contention between a derived activation transaction and a derived transaction, the nature of the derived transaction can be realized using a general DB lock mechanism.
[0148]
Next, an example of the derived transaction management will be described taking the cancellation / recut main in the earlier date completion processing system as an example.
If the transaction commit timing is not described in the program, the reusability of the program increases. For this reason, if the program that manages the execution of the transaction calls and executes the application program (APPL) and commits the program when it completes normally, APPL can be used in various ways. A program for managing transactions is called a business main here. In addition, as an execution form of APPL, when it is input for the first time from the terminal, when iteratively processes repeatedly, when it is called as a linked process, when it is started as a derived transaction, it is input as a center batch process There are some cases. Even if these transaction modes are different, some or all of the programs may be common. For this reason, if the program is subdivided and an appropriate program is specified according to the form of activation, the reusability of the program is enhanced and the total number of lines can be reduced.
[0149]
FIG. 13 is an explanatory diagram showing an example of an opcode table for providing such a mechanism. The business process request and the contents of the derived transaction are specified by the opcode. For example, the operation code for the withdrawal process of the ordinary deposit is 01001. In the case of the first terminal input, the
[0150]
Further, when receiving a request for starting a derived transaction, the business main calls a program for executing the processing shown in FIG. On the other hand, when the derived transaction is activated, the processing shown in FIG. 12 is executed before and after calling the APPL by the operation code of the derived transaction.
[0151]
As shown in FIG. 13, the opcode for savings and withdrawals is 01001. In a future date completion processing system, this ordinary deposit withdrawal may be canceled. This cancellation is a system in which a constant value (500 in the example shown in FIG. 13) is added to all the operation codes. This eliminates the need to search for an opcode when canceling a transaction. As shown in FIG. 13, the withdrawal of the ordinary deposit is activated in conjunction with or derived from the fixed deposit (03001) or periodic deposit (04001).
[0152]
FIG. 14 is an explanatory diagram showing an example of processing in the cancellation / recut main, and FIG. 14 (A) is a diagram showing an example of canceling the electric charge withdrawal (internal self-vibration) by account processing, and FIG. ) Is a diagram showing a transition of the balance by the processing. As shown in FIG. 14 (B), the 6-day balance is 60,000, and the deduction of electric charges (self-transfer number 12345) 20,000 with 7th as the account date is executed by the previous date completion process. Assume that the balance of the day is 40,000. In this state, when there is a deposit from the ordinary deposit to the term deposit using the ATM, the term deposit processing S21 activates the ordinary deposit withdrawal S22 of the
[0153]
In the periodical deposit, it is recorded in the term deposit master etc., and a response to the effect that the periodical deposit is completed is output to the ATM. On the other hand, in the ordinary deposit withdrawal S22, after updating the balance on the 6th, the balance on the 7th, which is the account date of the previous date, is also updated. The balance on the 7th will be minus 10,000. The ordinary deposit withdrawal S22 activates the cancellation / recut main with 7th as the account date since the balance on 7th is negative. The cancel / recut main controls to cancel the account processing that is established on the 7th until the minus of the withdrawal possible amount is resolved. Here, cancel the withdrawal of electricity charges is activated. In step S24, the withdrawal of the electric charge is canceled (operation code 02001 + 500 = 05021), and linked to the cancellation of the normal withdrawal. Canceling ordinary withdrawal (
[0154]
As shown in FIG. 14 (A), the periodic deposit and the ordinary withdrawal are interlocked and are one transaction T1. This is scheduled in the
[0155]
When the cancellation / recut main S23 activates the withdrawal process for electricity charges as the derivative activation transaction T2, it is highly likely that the transaction T1 for regular deposit and normal withdrawal has already been committed. In other words, the derivative activation transaction T1 commits without waiting for the commit of the derivative transaction T2 that is the cancel / recut main that is the accompanying task. If the transaction T1 is committed, the
[0156]
15 to 17 are explanatory diagrams for explaining the storage of the derivative activation information, the output of the derivative message, and the transition of the FIFO in this state. In this example, the IMS that operates in IBM's MVS is accelerated by FP, the FIFO and edit definition by SAIL is used, and each transaction is managed by the business main using the opcode table. In this example, the derivation index DB and the derivation management DB described in the second embodiment are used.
[0157]
The business main receives a business processing request for periodic deposit from the ATM in the form of an input message indicated by reference numeral M1 in FIG. In the input message M1, H is a header, an operation code is 04001 (see FIG. 13) indicating a periodic deposit, and the amount is 50,000. Here, withdrawing from the account 21yyy of the ordinary
[0158]
For savings and withdrawals, refer to the balance with the account date 2001/3/6 set in the FIFO to determine whether or not withdrawal is possible. Update balance to 10,000. And since the account date of the previous date exists, the balance of 7th is also updated. Since the balance on the 7th became negative, the start date (derivation date) for processing the cancel / recut main is set to 2001/3/7, and the derivative activation request is passed to the business main. For example, a derivative activation macro is executed. SAIL generates a derivation message (cancellation recut main) M2 from the contents of the normal withdrawal FIFO using the derivation edit definition. At this time, the business main calls the processing shown in FIG. As shown in FIG. 11, the called derivation request common process stores the contents of the normal withdrawal FIFO in the derivation management DB. In this example, since the job number is “000”, the index bit map of the
[0159]
As shown in FIG. 15, when the withdrawal of the ordinary deposit is successful, a result code (0000) indicating that the withdrawal was successful is recorded in the interlock return block using the interlock return edit definition. Since the periodic deposit process has succeeded in the regular deposit, an output message is generated from the periodic deposit FIFO using the output edit definition and transmitted to the ATM. As a result, the transaction T1 of JOBFP000 is committed.
[0160]
IMS schedules the derived message M2 to
[0161]
Derived message M3 is cancellation of self-vibration (electrical charge withdrawal), and the operation code is 02501. The transaction T3 cancels the self-vibration using the linked transaction, and the ordinary withdrawal cancellation process that is the linked passive business causes the derivative message M4 to be output. At this time, it is assumed that the transaction T3 is scheduled in the
[0162]
In the example shown in FIG. 17, the transaction T1 is committed at the time when the derivation request common process of the transaction T2 outputs the derivation message. This is because the derivative activation transaction T1 commits early without waiting for the commit of the derivative transaction T2, thereby ensuring the responsiveness of the periodic deposit process. On the other hand, the derived message (self-vibration cancellation) M3 is scheduled before the transaction T2 commits. For this reason, transaction T3 whose main business is self-cancellation is scheduled in
[0163]
When the transaction T2 commits, as shown in FIG. 12, the business main executes the derived characteristic management common processing (S76, S77) as a part of the transaction T2. Furthermore, in the example in which S78 and S79 are also executed as part of the transaction T2, the derived transaction T2 commits after the leading derived index bit of the
[0164]
In the example shown in FIG. 17, the update to OFF of the derived index DB (a corresponding derived management serial number can be used) is started as a separate transaction. In this case, the transaction T2 commits when step S77 is completed. At this time, the transaction T3 succeeds in reading the derivation management
[0165]
When the derived DB control process activated by the transaction T2 updates the index bit, the first bit of the index bit in the
[0166]
In the example shown in FIGS. 15 to 17, each region has been described as executing both a general transaction and a derived transaction. However, as shown in FIG. 18, the JOB number (region) is changed to a general transaction and a derived transaction. You may make it allocate separately. In the example shown in FIG. 18, since there is no possibility that all JOBs are used by a derived transaction, it is possible to prevent online responsiveness from deteriorating. In order to facilitate the handling of business process requests (messages), in the example shown in FIG. 18, the online system temporarily sends a message (message) requesting execution of online transactions or center batch processing as the queue 13. A
[0167]
<Total amount control>
Referring to FIG. 7 again, the online system (or transaction control system) includes a
[0168]
FIG. 19 is a flowchart illustrating an example of the stay monitoring process. When the staying number in the general queue or the derived queue is equal to or higher than a predetermined first level (steps S81 and S83), the
[0169]
FIG. 20 is a chart illustrating an example of processing for waiting for execution of a derived transaction. The total
[0170]
In addition, when the derivation stop bit stored in the
[0171]
Further, the total
[0172]
<Derived restart>
Next, restart of the derived transaction will be described. The derived transaction is restarted afterwards if it is aborted, if a system failure occurs during execution of the derived transaction, or if the activation of the derived transaction is canceled. By clarifying the procedure for restarting the derived transaction, it is possible to maintain the actual atomicity of the derived use transaction using the derived start transaction and the derived transaction.
[0173]
Referring to FIG. 7 again, the calculation means 4 is determined in advance after referring to the
[0174]
First, the mode of abort will be described. When the derivative activation transaction aborts, even if the derivative activation information has been stored, the update is invalidated by rollback, and the derivative management serial number busy flag is turned off. For this reason, the derived transaction is not activated (S74 in FIG. 12). Accordingly, the abort of the derivative activation transaction does not require the derivative transaction to be restarted.
[0175]
If the derived transaction aborts, even if the in-use flag is updated to enable, the update to enable is canceled by rollback. Thus, the atomicity of the derived transaction ensures that the in-use flag is in use when the derived transaction aborts. Accordingly, the derivative restart
[0176]
Also, when the derived index bit is executed in the derived DB control process in the end process of the derived transaction, when this derived DB control process is aborted, the update of the in-use flag by the derived transaction has succeeded and the commit has already been committed. Therefore, the in-use flag is off and the derived index bit is on. In this case, since the content of the incidental business of the derived transaction is normally committed, there is no need to restart the derived transaction.
[0177]
When the derivative
[0178]
FIG. 21 is a block diagram illustrating a configuration in which a derivation transaction is re-executed by derivation management work. When the
[0179]
When restarting all transactions, the derivation management task 92 starts the
[0180]
FIG. 22 is a flowchart showing a detailed configuration of the derivative restart necessity determination process by the derivative restart
Taking an account system as an example, for example, since the transfer process to another financial institution must be completed by a certain time, it is necessary to restart this derivative before entering the exchange interruption command to instruct this exchange interruption. Check whether there is a derivative transaction aborted by executing the judgment process. For example, the approval notification process described above uses a derived transaction, but confirms that the derived transaction is not aborted. In addition, since it is necessary that there is no derivative transaction (accompanying process) that needs to be restarted when the date is changed, the derivative restart necessity determination process is started by command input before the date change command is input.
Referring to FIG. 22, the derivative restart
The re-derivation unnecessary bit is set to ON in, for example, terminal return continuous processing. The derived index bit is in use and the in-use flag of the derived management DB is OFF when the derived transaction is committed and the derived DB control process is aborted, so that the derived transaction does not need to be restarted. If NO in step S97A, it is determined that the derivative transaction activated with the derivative management serial number needs to be derived again, and the
[0181]
If the derivation index bit is OFF (No at Step S94), or if it is ON but 30 seconds or more have not passed since the derivation transaction activation time (No at Step S96), the process goes through Steps S98A and S98B. The next index bit (next derivative management serial number) is determined. Even if 30 seconds or more have elapsed from the derivative transaction start time, the re-derivation unnecessary bit is ON, or the derivative DB control process is aborted even though the derivative transaction has been committed (in-use flag of the derivative management DB 70) (Yes in step S97A), the next index bit is determined.
In step S98A, it is confirmed whether or not the index bit position is final. If it is not the final position, the bit position is shifted by one and the corresponding next derivation management serial number is set as the processing target (step S98B), and the process proceeds to step S94. On the other hand, if the position of the index bit is final, the index area number corresponding to the next region is set as the determination target, so 1 is added to the target index area number and set, and the process proceeds to step S92. On the other hand, if the search for all index areas (regions) has been completed in step S99A, the derivation restart necessity determination process is terminated.
[0182]
FIG. 23 is a flowchart illustrating a processing example in which all the derived transactions that have been aborted or stopped are sequentially restarted with a single command. In the example shown in FIG. 23, the derivative
[0183]
When the in-use flag of the derivation management DB is “in use” and more than 5 minutes have passed since the entry of the derivation activation information, the derivation transaction is activated based on the derivation activation information stored in the
[0184]
If the number of re-derivation processes does not exceed a certain number in step S108, it is confirmed whether or not the search for all index area numbers (index bitmaps) has been completed (step S110). If the index bitmap remains, 1 is added to the target index area number, and the process proceeds to step S102. As a result, it is possible to search for the existence of a derived transaction aborted for all index bitmaps.
[0185]
As described above, according to the second embodiment, the derivation index DB can be accessed for each JOB number, and the derivation activation information is stored in the derivation management DB, thereby preventing contention between transactions processed in parallel. Thus, it is possible to manage the characteristics of the derived transaction using a general DB locking mechanism while preventing the occurrence of deadlock and further eliminating the need for reorganization of the derived management DB.
[0186]
[Third Embodiment]
In the derived characteristic management common process shown in FIG. 12, if step S79 is a process in a derived transaction, a deadlock may occur. This deadlock can be avoided depending on how the program is constructed. However, the matters to be noted by the programmer of the application program for the avoidance are complicated. For this reason, the third embodiment discloses a mechanism that can avoid the occurrence of deadlock while using a derived DB as an extension of the second embodiment. Specifically, step S79 is executed as a transaction (derived DB control process) different from the derived transaction.
[0187]
FIG. 24 is a block diagram showing a configuration of the present embodiment. The online system shown in FIG. 24 receives a business processing request (command) input from the
[0188]
The
[0189]
In the example shown in FIG. 24, the calculation means 4 includes a business
[0190]
In the calculation means 4, it is assumed that FP and SAIL provide various services on the IMS. When the message input means 8 (for example, SAIL input interface) shown in FIG. 24 receives a job processing request (input message), the input edit definition is based on the job identification code, medium type, and input edit number on the input message. Identify the table. In the present embodiment, the job identification code and the input edit number are converted from the operation code. The input interface performs the specified editing of the data on the message in accordance with the input editing definition table, and sets the edited data in the specified FIFO field. After this editing is completed, SAIL calls an application program corresponding to the job identification code. In this embodiment, a program called a business main that is common to all businesses is called.
[0191]
As shown in FIG. 25, the business
[0192]
When the business main receives the derivation activation request, it calls the derivation request common processing. That is, the business
[0193]
As shown in FIG. 25, when the derivation request common process is called and the process is started (1), the derivation request
[0194]
When the derivation request macro is output, the link interface of SAIL identifies the derivation edit definition table from the passive task identification code / edit number specified by the startup task identification code / program. In the present embodiment, the passive work identification code and the derived edit number are converted from the operation code of the derived passive process (derived transaction). The interlocking interface performs the specified editing and sets the data on the specified derivation startup business side FIFO in the derivation message according to the derivation edit definition table. When the linking interface receives the derivation message, it identifies the derivation edit definition table based on the start task identification code, passive task identification code, and derivation edit number on the input message. The interlocking interface sets the data on the derived message in the designated FIFO field after performing the designated editing in accordance with the derived editing definition table. After this editing is completed, SAIL calls the business main. Thereby, processing of the derived transaction is started. In the example shown in FIG. 25, the called business main executes the derived characteristic management
[0195]
In the present embodiment shown in FIG. 25, the “derived characteristic management
[0196]
As shown in FIG. 25, the derivative characteristic management
[0197]
The
[0198]
The
[0199]
FIG. 26 is an explanatory diagram illustrating an example of a deadlock that may occur when the derived index bit of the derived index DB is turned OFF when the derived transaction is completed as part of the derived transaction. That is, it is a diagram illustrating an example of a deadlock mode that may occur when the derived DB control process for specifying the derived management serial number using the derived
[0200]
A deadlock occurs when two transactions wait for each other's processing to complete. For example, the transaction T1 reads DBx, locks it, and then tries to read the derived index DB68. On the other hand, assume that transaction T2 reads the derived
[0201]
In the example shown in FIG. 26, first, a derivative activation request is output from JOBFP000, and this derivative transaction T2 is scheduled to JOBFP001. In transaction T2, although linked to another opcode, DBx that is the link destination is read with key y. In the transaction T2, after the interlocking process is completed, as a post-process of the derivative transaction (derivative characteristic management common process), the in-use flag of the derivation management DB is turned off, and the derivation index bit of the derivation index DB is turned off. At this time, since the key value of the derived index DB is the index area number, 0 which is the JOB number of
[0202]
During the processing of transaction T2, transaction T3 was scheduled with JOBFP000. In transaction T3, linked to another opcode, but in order to activate a derived transaction at the linked destination, the derived index DB is read with a key value of 0, and the derived activation information is stored in the segment of the derived management
[0203]
Now, in transaction T2, after reading DBx, it tries to read the derived index DB as the
[0204]
A technique for completely preventing the occurrence of deadlock is not to perform parallel processing, but this cannot be adopted. With respect to locks, in order to maintain serialization of parallel processing, some transactions need to follow a two-phase locking protocol with a phase of acquiring the lock and a phase of releasing the lock. Therefore, once a lock is released, the transaction must not acquire the lock. According to this two-phase locking protocol requirement, one transaction must be aborted if a deadlock occurs.
[0205]
A way to avoid deadlocks while maintaining parallelism is to adjust the order of transaction locks. For example, deadlock can be avoided if all transactions request locks in the same order. However, this is a severe limitation for programmers. In addition, by acquiring all locks used by the transaction at the start of the transaction and then performing the actual processing, it is possible to avoid the occurrence of deadlocks. The benefits of parallel processing are reduced.
[0206]
In order to avoid deadlocks with these standard methods, it is necessary to read the DB to be read after linking before linking before linking to linked passive processing that may start a derived transaction. . Thereby, the execution order becomes the same. If all the interlock activation processes satisfy this condition, it is possible to avoid the occurrence of the deadlock shown in FIG. However, it is difficult and difficult for the developer of the linked activation work to be aware of keeping this DB reading order.
[0207]
For this reason, in the third embodiment, as the derived DB control process, the process of turning off the derived index bit of the derived index DB is a separate transaction. For this reason, in the derived characteristic management common processing, the derived index bit of the derived index DB is not updated. Therefore, the DBx lock and the derived index DB lock are not performed within one transaction. Since the derived DB control process does not read any DB other than the derived DB (the derived management DB and the derived index DB), no deadlock occurs.
[0208]
With reference to FIG. 25 again, the derived transaction management method in this embodiment will be described. The derived transaction management method executes the derived start transaction (derived start APPL 111A) and commits the derived start transaction without waiting for the commit of the derived transaction (derived passive APPL 113A) requested for start by the derived start transaction. A derivative transaction management process (100A, 112A), a derivative transaction management process (derivative property management
[0209]
The derivative activation transaction management step refers to the derivation index DB according to the job number of the derivative activation transaction as a part of the derivative activation transaction, specifies the derivation management serial number of the derivation management DB, and relates to the derivation management. Derivation request common processing step (derivation request) for storing the derivative activation information in the serial number segment, updating the index bit and the in-use flag corresponding to the used derivation management serial number while in use, and activating the derivative transaction.
[0210]
The derived transaction management step derives the derived management serial number given to the derived transaction as a key value when the derived transaction is started and scheduled in the derived request
[0211]
In the derivative DB management step, when the derivative DB control process is scheduled, the derivative management serial number of the derivative management DB in which derivative activation information for restarting the derivative transaction including the derivative passive business program is stored. A derivation DB control processing step (derivation DB
[0212]
Further, as shown in FIG. 24, each configuration of the total
[0213]
In the third embodiment, restart of the aborted derived transaction is the same as in the second embodiment. When the business main 100A and the derivative activation APPL abort, both the in-use flag and the derivative index bit remain usable, and no derivative transaction activation request is made. When the derivation request
[0214]
Even if the derived request
[0215]
When the derivation start transaction is committed, it is recorded with durability in the derivation management DB with the in-use flag set to “in use”. In case of (1) to (5) of the derived characteristic management
[0216]
Assume that the derived DB control process is aborted after the derived characteristic management common process is committed. In this case, the in-use flag is off. However, the derived index bit of the derived index DB remains ON. Thus, (1). In the case of abort of a derivative start transaction, the derivative transaction is not started. (2). When the derivation transaction is committed but the derivation passive APPL 113A and the derivation characteristic management
[0217]
Derived transactions need to be restarted (2). This is the case. Accordingly, by searching for a process in which the in-use flag is ON and a certain time has elapsed since activation, it is possible to specify a derived transaction that should be determined as to whether or not reactivation is necessary. (3). In the case of aborting the derived
[0218]
As described above, according to the present embodiment, a deadlock that occurs in a state where derivation and interlocking are intricately intertwined can be avoided by the derivation DB control process, so that the developer does not need to make adjustments in program creation. .
[0219]
【The invention's effect】
The present invention is divided into an online transaction that requires an online response and a derivative transaction that executes a process associated with the online transaction or the like depending on the configuration. Therefore, processing required for online response is processed as an online transaction, and incidental processing not required for online response is used as a derived transaction.After committing an online transactionTo process. Therefore, the online transaction can be committed early. ThisTheIt is possible to process only incidental operations as derived transactions afterwards while ensuring online responsiveness. Therefore, processing that is conventionally performed in batch processing can be performed in parallel with online transactions using derived transactions. As described above, according to the present invention, by using the derived transaction model, online responsiveness can be achieved while executing processing that has been realized by conventional batch processing or processing that increases the processing amount as one transaction. Can be securedUtoA transaction control system can be realized..
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration of an online transaction control system according to the present embodiment.
FIG. 2 is an explanatory diagram for explaining the nature of a derived transaction. FIG. 2A is a diagram showing an example in which a derived transaction activation request is made from a derived activated transaction, and FIG. FIG. 2C is a diagram illustrating a case where the derived activation transaction is a linked transaction, and FIG. 2C is a diagram illustrating an example in which the derived transaction requests activation as a derived transaction.
FIG. 3 is an explanatory diagram for explaining a terminal response or the like according to a method of using a derived transaction, FIG. 3 (A) is a diagram showing a case of an accompanying service, and FIG. 3 (B) is a diagram. It is a figure which shows the case of cancellation recut main.
FIG. 4 is an explanatory diagram illustrating an operation example of cancel / recut main.
FIG. 5 is an explanatory diagram showing an example in which a derived transaction is used for terminal return continuous processing;
FIG. 6 is a flowchart illustrating an example of transaction total amount control;
FIG. 7 is a block diagram illustrating a configuration of a second embodiment.
FIG. 8 is an explanatory diagram showing a relationship between a JOB and a derived index DB.
FIG. 9 is an explanatory diagram illustrating data items in the derivation DB, FIG. 9A is a diagram illustrating an example of items in the derivation index DB, and FIG. 9B is an example of items in the derivation management DB; FIG.
FIG. 10 is an explanatory diagram illustrating the relationship between a job ID, an index area number of a derived index DB, a bit position, and a derived management serial number. FIG. 10 (A) is executed with JOB ID000. FIG. 10B is a diagram showing an example of the contents of the derivation management DB in this case, and FIG. FIG. 10 is a diagram showing a relationship between a derived index DB read by a transaction executed with JOB ID001, its bit position, and a derived management serial number, and FIG. 10D is a diagram showing an example of contents of the derived management DB in this case. .
FIG. 11 is a flowchart illustrating an example of a derivation request management process for managing derivation transaction requests.
FIG. 12 is a flowchart illustrating an example of a derived characteristic management process for managing the characteristics of a derived transaction.
FIG. 13 is a diagram illustrating an example of an operation code table, and here, an example of an operation code table for an ordinary deposit is illustrated.
FIG. 14 is an explanatory diagram showing an example of processing in the cancellation / recut main, and FIG. 14 (A) is a diagram showing an example of canceling the electric charge withdrawal (internal self-vibration) by account processing; FIG. 14B is a diagram showing the transition of the balance by the processing.
FIG. 15 is an explanatory diagram illustrating an example of FIFO transitions and derived messages in the process illustrated in FIG. 14;
FIG. 16 is an explanatory diagram showing changes in FIFO and the like following FIG. 15;
FIG. 17 is an explanatory diagram illustrating an example of using a derived DB in the examples illustrated in FIGS. 14 and 15;
FIG. 18 is an explanatory diagram illustrating an example in which a JOB is allocated to a general transaction and a derived transaction separately.
FIG. 19 is a flowchart illustrating an example of a stay monitoring process.
FIG. 20 is a chart illustrating an example of a total amount control process for waiting for execution of a derived transaction.
FIG. 21 is a block diagram illustrating an example of restart processing of an aborted derived transaction.
FIG. 22 is a flowchart illustrating an example of processing for determining whether or not a derived transaction needs to be restarted.
FIG. 23 is a flowchart illustrating an example of a derived transaction restart process;
FIG. 24 is a block diagram showing the configuration of the third embodiment;
FIG. 25 is an explanatory diagram showing a configuration of derivation management processing;
FIG. 26 is an explanatory diagram illustrating an example of a deadlock that may occur when the derived DB control process is not a separate transaction.
[Explanation of symbols]
2 Receiving means
4 Calculation means
6 files
8 Message input means
10 Online response section
12 Derived Transaction Management Department
14 Total control unit
16 Transaction execution part
Claims (19)
前記演算手段は、
所定のオンライントランザクション及び所定の派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルのデータ項目をロックし、処理し、前記ファイルに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理する派生トランザクション管理部とを備えたトランザクション制御システムにおいて、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記派生トランザクション管理部は、
前記派生トランザクションの起動と開始とを管理し、
前記起動要求依頼が出力された際に、当該派生トランザクションの起動処理とは別に、当該派生トランザクションの起動要求依頼に関連する派生起動情報を前記ファイルに記録し、当該派生起動情報の記録を、前記派生起動トランザクションの原子性に包む制御をすることで、派生トランザクションの起動を管理する派生起動情報格納制御機能と、
当該起動要求依頼された派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせる機能と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、当該起動要求依頼された派生トランザクションの処理を開始させることで、前記派生トランザクションの開始を管理する直列性管理機能とを備えたことを特徴とするトランザクション制御システム。Receiving means for receiving a business processing request input via the end-terminal or the network from a computing means for processing the business processing request received by the receiving means, and a file for recording the processing results of the arithmetic means With
The computing means is
A predetermined online transaction and a predetermined derivative transaction are executed in parallel, and when executing each transaction, the data item of the file is locked and processed, and the processing result is recorded in the file. A transaction execution part that releases the lock;
Online response unit for the control of outputting the business processing request input said end late or found to be processed to the transaction execution section as online transaction, the processing result of the online transaction in response to said terminal,
In a transaction control system comprising a derivative transaction management unit that causes the transaction execution unit to process the derivative transaction and manages commit of each transaction,
During the execution of each transaction, a transaction that outputs a request for starting a new transaction is referred to as a derived start transaction, and the transaction requested for the start request is a derived transaction.
The derived transaction is a transaction that occurs in association with the processing result of the online transaction and processes all or part of an incidental service that is not necessary for the response of the online transaction,
The derived transaction management unit
Managing the start and start of the derived transaction;
When the start demand request is output, separately from the start processing of the derived transaction records derived activation information associated with the activation request request of the faction raw transaction with the file, the record of the derived start information, by the control wrap the atoms of the previous SL-derived activated transaction, and a derived startup information storage control function for managing the activation of the derived transaction,
A function to commit the derived start transaction without waiting for the start of the start demand request Derived transactions,
When the derivative activation transaction is committed, the lock by the derivative activation transaction is released to allow access to the unlocked data item by another online transaction, while the derivative transaction requested for the activation request. by starting the process, the transaction control system being characterized in that a series of management functions for managing the start of the derived transaction.
前記総量制御部は、実行を待機しているトランザクションの総数を監視する実行状況監視機能と、
この実行状況監視機能によって実行待機中のトランザクション数が予め定められた数を超えたと判定された場合には、前記派生起動情報が前記ファイルに記録された状態で派生トランザクションの開始を中止する派生起動中止制御機能を備えたことを特徴とする請求項１又は２記載のトランザクション制御システム。The computing means includes a total amount control unit that limits the start of the derived transaction according to the total amount of each transaction whose execution is managed by the online response unit and the derived transaction management unit ,
The total amount control unit, an execution status monitoring function for monitoring the total number of transactions waiting to be executed,
If the number of transactions waiting to be executed by the execution status monitoring function This is determined to have exceeded the predetermined number stops the start of the derived transaction in a state in which the derived start information is recorded in the file transaction control system according to claim 1, wherein further comprising a derivation startup disabling control function.
前記派生起動トランザクションの実行によって業務上の一貫性に関して中間的なデータが生じる場合には当該中間的なデータについて耐久性を持った状態で前記ファイルに記録し、
この業務処理要求の実行によって生じた業務上の一貫性に関する中間的な状態を解消して業務上の一貫性を保つための判定及び実行を前記派生トランザクションとして実行することを特徴とする請求項１，２又は３記載のオンラインシステム。The transaction execution unit
When intermediate data regarding business consistency is generated by the execution of the derivative activation transaction, the intermediate data is recorded in the file in a durable state,
Claim 1, characterized in that to perform the determination and execution and to maintain the integrity of the business by eliminating the intermediate state regarding consistency business caused by the execution of the business process request as the derived transaction , 2 or 3 online system.
この演算手段は、
所定のオンライントランザクション及び所定の派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルのデータ項目をロックし、処理し、前記ファイルに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理する派生トランザクション管理部とを備えたトランザクション制御システムの前記派生トランザクション管理部を使用して、
前記各トランザクションを管理するトランザクション制御方法であって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記起動要求依頼が出力された際に、当該派生トランザクションの起動処理とは別に、当該派生トランザクションの起動要求依頼に関連する派生起動情報を前記ファイルに記録し、当該派生起動情報の記録を、前記派生起動トランザクションの原子性に包む制御をすることで、派生トランザクションの起動を管理する工程と、
前記派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせる工程と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、当該起動要求依頼された派生トランザクションの処理を開始させることで、前記派生トランザクションの開始を管理する工程とを備えたことを特徴とするトランザクション制御方法。Receiving means for receiving a business processing request input via the end-terminal or the network from a computing means for processing the business processing request received by the receiving means, and a file for recording the processing results of the arithmetic means With
This computing means is
A predetermined online transaction and a predetermined derivative transaction are executed in parallel, and when executing each transaction, the data item of the file is locked and processed, and the processing result is recorded in the file. A transaction execution part that releases the lock;
An online response unit that controls the transaction execution unit to process a business process request input from the terminal as an online transaction, and outputs a processing result of the online transaction as a response to the terminal;
Using the derived transaction management unit of a transaction control system including a derived transaction management unit that causes the transaction execution unit to process the derived transaction and manages commit of each transaction ,
Wherein a belt transaction control method to manage the transaction,
During the execution of each transaction, a transaction that outputs a request for starting a new transaction is referred to as a derived start transaction, and the transaction requested for the start request is a derived transaction.
The derived transaction is a transaction that occurs in association with the processing result of the online transaction and processes all or part of an incidental service that is not necessary for the response of the online transaction,
When prior Symbol starting demand request is output, separately from the start processing of the derived transaction records derived activation information associated with the activation request request the derived transaction on the file, the record of the derived start information, Managing the start of the derived transaction by controlling the atomicity of the derived start transaction ;
A step of committing the derived start transaction without waiting for the start of the derived transaction,
When the derivative activation transaction is committed, the lock by the derivative activation transaction is released to allow access to the unlocked data item by another online transaction, while the derivative transaction requested for the activation request. by starting the process, it features and to belt transaction control method further comprising the step of managing the starting of the derived transaction.
この演算手段は、
所定のオンライントランザクション及び所定の派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルのデータ項目をロックし、処理し、前記ファイルに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理する派生トランザクション管理部とを備えたトランザクション制御システムの前記派生トランザクション管理部に所定の工程を実現させるためのトランザク ション制御プログラムであって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記派生起動トランザクションから派生トランザクションの起動要求依頼が出力された際の処理の工程として、前記派生トランザクション管理部に対して、
前記起動要求依頼が出力された際に、当該派生トランザクションの起動処理とは別に、当該派生トランザクションの起動要求依頼に関連する派生起動情報を前記ファイルに記録し、当該派生起動情報の記録を、前記派生起動トランザクションの原子性に包む制御をすることで、派生トランザクションの起動を管理する工程と、
前記派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせる工程と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、当該起動要求依頼された派生トランザクションの処理を開始させることで、前記派生トランザクションの開始を管理する工程とを実現させることを特徴とするトランザクション制御プログラム。Receiving means for receiving a business processing request input via the end-terminal or the network from a computing means for processing the business processing request received by the receiving means, and a file for recording the processing results of the arithmetic means With
This computing means is
A predetermined online transaction and a predetermined derivative transaction are executed in parallel, and when executing each transaction, the data item of the file is locked and processed, and the processing result is recorded in the file. A transaction execution part that releases the lock;
An online response unit that controls the transaction execution unit to process a business process request input from the terminal as an online transaction, and outputs a processing result of the online transaction as a response to the terminal;
In transaction control program for causing the derived transaction is processed on the transaction execution section, realize a predetermined process on the derivation transaction management section of the transaction control system that includes a derivative transaction management unit for managing committing each transaction There,
Wherein during execution of the transaction, the transaction that outputs an activation request request for a new transaction with a derived activated transaction, the activation request requested transaction as a derived transaction,
The derived transaction is a transaction that occurs in association with the processing result of the online transaction and processes all or part of an incidental service that is not necessary for the response of the online transaction,
As a process step when a request for starting a derived transaction is output from the derived start transaction, for the derived transaction management unit,
When prior Symbol starting demand request is output, separately from the start processing of the derived transaction records derived activation information associated with the activation request request the derived transaction on the file, the record of the derived start information, by the control wrap the atoms of the derivative start transaction, a step of managing the activation of the derived transaction,
A step of committing the derived start transaction without waiting for the start of the derived transaction,
When the derivative activation transaction is committed, the lock by the derivative activation transaction is released to allow access to the unlocked data item by another online transaction, while the derivative transaction requested for the activation request. by starting the process, the transaction system Gopu program, characterized in that to realize the process of managing the starting of the derived transaction.
前記ファイルが、前記業務処理要求に関連した各種マスタＤＢと、所定の派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録する派生管理ＤＢと、この派生管理ＤＢのキーとなる派生管理通番毎に派生管理ＤＢが使用中であるか否かを指示するインデックス情報を記録する派生インデックスＤＢとを備え、
前記演算手段が、
所定のオンライントランザクション及び前記派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理するトランザクション管理部とを備え、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記トランザクション管理部が、前記派生起動トランザクションから新たな派生トランザクションの起動要求依頼が出力された際には、前記派生インデックスＤＢのインデックス情報を特定すると共に当該特定したインデックス情報に基づいて前記派生管理ＤＢの使用可な派生管理通番を特定する派生管理通番特定機能と、
この派生管理通番特定機能によって特定された派生管理通番のセグメントに、当該派生トランザクションの起動処理とは別に、当該起動要求された派生トランザクションの派生起動情報を記録し、当該派生起動情報の記録を前記派生起動トランザクションの原子性に 包む制御をし、当該派生起動情報の記録後に、当該派生トランザクションを起動させる派生起動情報格納制御機能と、
当該派生起動トランザクションの各処理が正常終了した際に、当該起動要求依頼された派生トランザクションの開始を待機せずに、当該派生起動トランザクションをコミットさせる派生起動トランザクションコミット処理機能と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、前記起動された派生トランザクションが当該派生管理通番の前記派生起動情報をロック可能な状態での正常な読み出しに成功した後に、当該派生トランザクションの各処理を開始させる直列性制御機能と、
前記派生トランザクションの各処理が正常終了した際に、当該派生管理通番の前記派生インデックスＤＢ及び前記派生管理ＤＢを使用可に更新させると共に当該派生トランザクションをコミットさせる派生トランザクションコミット処理機能と、
前記派生トランザクションがアボートされた際に、前記派生管理ＤＢに格納した派生起動情報に基づいた再起動を制御する派生再起動制御機能とを備えたことを特徴とするトランザクション制御システム。Receiving means for receiving a business processing request input via the end-terminal or the network from a computing means for processing the business processing request received by the receiving means, and a file for recording the processing results of the arithmetic means With
The file includes various master DBs related to the business process request, a derivative management DB that records derivative activation information associated with a request for starting a predetermined derivative transaction for each derivative management serial number, and a key of the derivative management DB A derivation index DB for recording index information indicating whether the derivation management DB is in use for each derivation management serial number,
The computing means is
A predetermined online transaction and the derived transaction are executed in parallel, and when each transaction is executed, the data item of each DB of the file is locked and processed, and the processing result is recorded in each DB of the file. And a transaction execution unit for releasing the lock after the recording,
Online response unit for the control of outputting the business processing request input said end late or found to be processed to the transaction execution section as online transaction, the processing result of the online transaction in response to said terminal,
A transaction management unit that causes the transaction execution unit to process the derived transaction and manages commit of each transaction ;
During the execution of each transaction, a transaction that outputs a request for starting a new transaction is referred to as a derived start transaction, and the transaction requested for the start request is a derived transaction.
The derived transaction is a transaction that occurs in association with the processing result of the online transaction and processes all or part of an incidental service that is not necessary for the response of the online transaction,
The transaction management unit, when a start request requesting the new derived transaction before Symbol school students start transaction is output, the derived based on the specified index information together with identifying the index information of the derived index DB Derived management serial number specifying function for specifying the available management number of the management DB,
The segment derived management serial number specified by this derived management serial number specific function, apart from the activation processing of the derived transaction, it records a derived activation information of the activation request Derived transactions, a record of the derived start information Derived activation information storage control function for controlling the wrapping in the atomicity of the derived activation transaction and activating the derived transaction after recording the derived activation information;
When each processing of this the derivative raw start transaction is successful, without waiting for the start of the start demand request Derived transactions, the derived start transaction commit processing function to commit the derived start transaction,
When the derived start transaction commits, while allowing access by other online transaction by releasing the locking by the derived start transaction to the unlocked data item, the activation Derived transactions the A seriality control function for starting each process of the derived transaction after successfully reading the derived activation information of the derived management serial number in a lockable state;
When each processing of the derived transaction is successful, and the derived transaction commit processing function to commit the derived transaction with to update the derived index DB and the derivation management DB of the derivation management serial numbers usable,
A transaction control system comprising: a derivative restart control function for controlling restart based on the derivative activation information stored in the derivative management DB when the derivative transaction is aborted.
前記派生インデックスＤＢが、前記派生起動トランザクションのＪＯＢ番号をキー値とするインデックス領域番号毎に前記インデックス情報を有することを特徴とした請求項７記載のトランザクション制御システム。The derivative activation transaction is executed with any JOB number in a predetermined JOB number group,
The derived index DB is, transaction control system according to claim 7, wherein which is characterized by having the index information for each index area number the JOB number of the derived activated transaction shall be the key value.
前記派生管理通番特定機能が、前記インデックス領域番号と前記ビットマップのビット位置とに基づいて前記派生管理ＤＢの派生管理通番を特定する機能を備えたことを特徴とする請求項８記載のトランザクション制御システム。The derived index DB holds the index information as a bitmap for each index area number,
The derivation management serial number specific function, the index area number and bets la according to claim 8, further comprising a function for identifying the derivation management serial number of the derivation management DB on the basis of the bit position in the bitmap Transaction control system.
前記派生管理ＤＢが、前記派生管理通番毎に当該派生管理通番の使用状態を使用中又は使用可として記録する使用中フラグを有し、
前記派生管理通番特定機能が、ＯＦＦとなっている派生インデックスビット及び当該使用可となっている派生管理通番を特定したときに当該派生インデックスビットについて使用中を示すＯＮへと更新し、
前記派生起動情報格納制御機能が、前記派生起動情報を格納したときに当該派生管理通番の使用中フラグを「使用中」へと更新し、
前記直列性制御機能は、前記派生起動トランザクションから渡された派生管理通番の使用中フラグが使用可であった場合には、当該派生トランザクションがアボートしたとして、当該起動要求されている派生トランザクションを開始せずにアボートさせ、
派生トランザクションコミット制御機能は、当該派生トランザクションの完了時又は完了後に前記派生インデックスビット及び前記使用中フラグについて使用可へと更新することを特徴とする請求項９記載のトランザクション制御システム。The derivation index DB has a bitmap for each index area number as a derivation index bit, and records the use status of the derivation management DB corresponding to the bit position of the bit according to ON or OFF of the derivation index bit. ,
The derivation management DB has an in-use flag for recording the use state of the derivation management serial number as being used or available for each derivation management serial number,
When the derivation management serial number specifying function specifies a derivation index bit that is OFF and a derivation management serial number that is enabled, the derivation management serial number is updated to ON indicating that the derivation index bit is in use,
When the derivative activation information storage control function stores the derivative activation information, it updates the in-use flag of the derivative management serial number to “in use”.
The series of control functions, when use flag derived management serial number passed from the derived activated transaction was usable as the derived transaction aborts, starts a derivative transaction that is the activation request Abort without
10. The transaction control system according to claim 9 , wherein the derived transaction commit control function updates the derived index bit and the in-use flag to be usable when the derived transaction is completed or after completion.
前記演算手段が、前記一般待ち行列及び派生待ち行列で滞留しているトランザクション数を監視する滞留監視部と、この滞留監視部によって監視される各待ち行列でのトランザクションの滞留数に応じて前記派生起動トランザクション又は前記派生トランザクションの起動を制御する総量制御部とを備え、
前記滞留監視部は、前記一般待ち行列又は派生待ち行列の滞留数が予め定められたレベル以上である場合には派生中止ビットをＯＮとし、
前記総量制御部は、前記派生中止ビットがＯＮである場合には派生起動要求があった時には当該派生起動情報を前記派生管理ＤＢに記録後、派生トランザクションの開始を行わない派生起動中止制御機能とを備えたことを特徴とする請求項８記載のトランザクション制御システム。 Said calculating means, said online transaction and parallel to the unit the JOB number a predetermined number of said derivative transaction processes, requests for each transaction that is scheduled to the JOB number of arithmetic means this comprising temporarily storing to queue, this queue has the general queue for temporarily storing the online transaction requests, and a derivative queue for temporarily storing a request for the derived transaction,
The operation means monitors the number of transactions remaining in the general queue and the derivative queue, and the derivation according to the number of transactions remaining in each queue monitored by the retention monitor A total amount control unit for controlling the start of the start transaction or the derived transaction ,
Before SL residence monitoring unit, when staying number of the general queue or derivative queue is level than the predetermined is set to ON Derived stop bit,
The total amount control unit, when the derivation stop bit is ON, when there is a derivation start request, after the derivation start information is recorded in the derivation management DB, a derivation start stop control function that does not start a derivation transaction; 9. The transaction control system according to claim 8, further comprising:
前記演算手段は、前記派生インデックスＤＢ及び前記派生管理ＤＢを参照して、前記インデックス情報が使用中を示し、かつ、前記起動時刻を参照して、派生管理ＤＢに派生起動情報を格納した後予め定められた時間以上経過している派生管理通番を派生再起動要と判定する派生再起動要否監視部を備えたことを特徴とする請求項７又は８記載のトランザクション制御システム。 The derived activation information storage control function stores information related to the activation request of the derived transaction by the derived activation transaction and the activation time as derived activation information in the segment of the derived management sequence number specified by the derived management sequence number specifying function ,
It said calculation means, by referring to the derived indices DB and the derivation management DB, the index information indicates busy, One or, with reference to the start time, after storing the derived start information is derived management DB transaction control system according to claim 7 or 8, wherein further comprising a derivation restart essential and determines a derived restart necessity monitoring unit derived management serial number has passed a predetermined time or more.
前記ファイルが、前記業務処理要求に関連した各種マスタＤＢと、所定の派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録する派生管理ＤＢと、この派生管理ＤＢのキーとなる派生管理通番毎に派生管理ＤＢが使用中であるか否かを指示するインデックス情報を記録する派生インデックスＤＢとを備え、
前記演算手段が、
所定のオンライントランザクション及び前記派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理するトランザクション管理部とを備えたトランザクション制御システムの前記トランザクション管理部を使用して、
前記各トランザクションを管理するトランザクション制御方法であって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記派生起動トランザクションから新たな派生トランザクションの起動要求依頼が出力された際には、前記派生インデックスＤＢのインデックス情報を特定すると共に当該特定したインデックス情報に基づいて前記派生管理ＤＢの使用可となっている派生管理通番を特定する派生管理通番特定工程と、
この派生管理通番特定工程にて特定された派生管理通番のセグメントに、当該派生トランザクションの起動処理とは別に、当該起動要求依頼された派生起動トランザクションの派生起動情報を記録し、当該派生起動情報の記録を前記派生起動トランザクションの原子性に包む制御をし、当該派生起動情報の記録後に、当該派生トランザクションを起動させる派生起動情報格納制御工程と、
当該派生起動トランザクションの各処理が正常終了した際に、当該起動要求依頼された派生トランザクションの開始を待機せずに、当該派生起動トランザクションをコミットさせる派生起動トランザクションコミット処理工程と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、前記派生トランザクションが当該派生管理通番の前記派生起動情報をロック可能な状態での正常な読み出しに成功した後に、当該派生トランザクションの各処理を開始させる直列性制御工程と、
前記派生トランザクションの各処理が正常終了した際に、当該派生管理通番の前記派生インデックスＤＢ及び前記派生管理ＤＢを使用可に更新させると共に当該派生トランザクションをコミットさせる派生トランザクションコミット処理工程と、
前記派生トランザクションがアボートされた際に、前記派生管理ＤＢに格納した派生起動情報に基づいた再起動を制御する派生再起動制御工程とを備えたことを特徴とするトランザクション制御方法。Receiving means for receiving a business processing request input via the end-terminal or the network from a computing means for processing the business processing request received by the receiving means, and a file for recording the processing results of the arithmetic means With
The file includes various master DBs related to the business process request, a derivative management DB that records derivative activation information associated with a request for starting a predetermined derivative transaction for each derivative management serial number, and a key of the derivative management DB A derivation index DB for recording index information indicating whether the derivation management DB is in use for each derivation management serial number ,
The computing means is
A predetermined online transaction and the derived transaction are executed in parallel, and when each transaction is executed, the data item of each DB of the file is locked and processed, and the processing result is recorded in each DB of the file. And a transaction execution unit for releasing the lock after the recording,
An online response unit that controls the transaction execution unit to process a business process request input from the terminal as an online transaction, and outputs a processing result of the online transaction as a response to the terminal;
Using the transaction management unit of a transaction control system including a transaction management unit that causes the transaction execution unit to process the derived transaction and manages commit of each transaction ,
Wherein a belt transaction control method to manage the transaction,
During the execution of each transaction, a transaction that outputs a request for starting a new transaction is referred to as a derived start transaction, and the transaction requested for the start request is a derived transaction.
The derived transaction is a transaction that occurs in association with the processing result of the online transaction and processes all or part of an incidental service that is not necessary for the response of the online transaction,
When activation request requesting a new derivative transaction before Symbol school students start transaction is output, and usable in the derivation management DB on the basis of the specified index information together with identifying the index information of the derived index DB A derivation management sequence number identifying step for identifying the derivation management sequence number,
This derivation management serial number segments derived management serial number identified by a particular process, apart from the activation processing of the derived transaction, records a derived activation information of the activation request requested Derived started transaction, the derived start information A derivative activation information storage control step of activating the derivative transaction after recording the derivative activation information.
When each processing of this the derivative raw start transaction is successful, without waiting for the start of the start demand request Derived transactions, the derived start transaction commit processing step of committing the derived start transaction,
When the derived activation transaction is committed, the derived transaction is permitted to access the unlocked data item by other online transactions by releasing the lock by the derived activation transaction, and the derivative management serial number after successful the derived start information to the normal reading in lockable state of a series of control steps for starting the processing of the derived transaction,
A derivative transaction commit processing step of updating the derivative index DB and the derivative management DB of the derivative management serial number to be usable and committing the derivative transaction when each process of the derivative transaction is normally completed;
When the derived transaction is aborted, features and to belt transaction control method further comprising a derivation restart control step of controlling a restart based on the derived start information stored in the derivation management DB.
前記ファイルが、前記業務処理要求に関連した各種マスタＤＢと、所定の派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録する派生管理ＤＢと、この派生管理ＤＢのキーとなる派生管理通番毎に派生管理ＤＢが使用中であるか否かを指示するインデックス情報を記録する派生インデックスＤＢとを備え、
前記演算手段が、
所定のオンライントランザクション及び前記派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理するトランザクション管理部とを備えたトランザクション制御システムの前記トランザクション管理部に所定の工程を実現させるためのトランザクション制御プログラムであって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記派生起動トランザクションから派生トランザクションの起動要求依頼が出力された際の処理の工程として、前記派生トランザクション管理部に対して、
前記オンライントランザクション又は派生トランザクションである派生起動トランザクションから新たな派生トランザクションの起動要求依頼が出力された際には、前記派生インデックスＤＢのインデックス情報を特定すると共に当該特定したインデックス情報に基づいて前記派生管理ＤＢの使用可となっている派生管理通番を特定する派生管理通番特定工程と、
この派生管理通番特定工程にて特定された派生管理通番のセグメントに、当該派生トランザクションの起動処理とは別に、当該起動要求依頼された派生起動トランザクションの派生起動情報を記録し、当該派生起動情報の記録を前記派生起動トランザクションの原子性に包む制御をし、当該派生起動情報の記録後に、当該派生トランザクションを起動させる派生起動情報格納制御工程と、
当該派生起動トランザクションの各処理が正常終了した際に、当該起動要求依頼された派生トランザクションの開始を待機せずに、当該派生起動トランザクションをコミットさせる派生起動トランザクションコミット処理工程と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、前記派生トランザクションが当該派生管理通番の前記派生起動情報をロック可能な状態での正常な読み出しに成功した後に、当該派生トランザクションの各処理を開始させる直列性制御工程と、
前記派生トランザクションの各処理が正常終了した際に、当該派生管理通番の前記派生インデックスＤＢ及び前記派生管理ＤＢを使用可に更新させると共に当該派生トランザクションをコミットさせる派生トランザクションコミット処理工程と、
前記派生トランザクションがアボートされた際に、前記派生管理ＤＢに格納した派生起動情報に基づいた再起動を制御する派生再起動制御工程とを実現させることを特徴とするトランザクション制御プログラム。Receiving means for receiving a business processing request input via the end-terminal or the network from a computing means for processing the business processing request received by the receiving means, and a file for recording the processing results of the arithmetic means With
The file includes various master DBs related to the business process request, a derivative management DB that records derivative activation information associated with a request for starting a predetermined derivative transaction for each derivative management serial number, and a key of the derivative management DB A derivation index DB for recording index information indicating whether the derivation management DB is in use for each derivation management serial number ,
The computing means is
A predetermined online transaction and the derived transaction are executed in parallel, and when each transaction is executed, the data item of each DB of the file is locked and processed, and the processing result is recorded in each DB of the file. And a transaction execution unit for releasing the lock after the recording,
An online response unit that controls the transaction execution unit to process a business process request input from the terminal as an online transaction, and outputs a processing result of the online transaction as a response to the terminal;
A transaction control program for causing the transaction execution unit to process the derived transaction and realizing a predetermined process in the transaction management unit of a transaction control system including a transaction management unit that manages commit of each transaction ,
During the execution of each transaction, a transaction that outputs a request for starting a new transaction is referred to as a derived start transaction, and the transaction requested for the start request is a derived transaction.
The derived transaction is a transaction that occurs in association with the processing result of the online transaction and processes all or part of an incidental service that is not necessary for the response of the online transaction,
As a process step when a request for starting a derived transaction is output from the derived start transaction, for the derived transaction management unit ,
When activation request requesting a new derivative transactions from the a-line transaction or derived transaction derived activated transaction is output, the derivation management on the basis of the specified index information together with identifying the index information of the derived index DB Derivation management serial number identification process for identifying the derivation management serial number for which the DB can be used;
This derivation management serial number segments derived management serial number identified by a particular process, apart from the activation processing of the derived transaction, records a derived activation information of the activation request requested Derived started transaction, the derived start information A derivative activation information storage control step of activating the derivative transaction after recording the derivative activation information.
When each processing of this the derivative raw start transaction is successful, without waiting for the start of the start demand request Derived transactions, the derived start transaction commit processing step of committing the derived start transaction,
When the derived activation transaction is committed, the derived transaction is permitted to access the unlocked data item by other online transactions by releasing the lock by the derived activation transaction, and the derivative management serial number after successful the derived start information to the normal reading in lockable state of a series of control steps for starting the processing of the derived transaction,
When each processing of the derived transaction is successful, and the derived transaction commit processing step of committing the derived transaction with to update the derived index DB and the derivation management DB of the derivation management serial numbers usable,
Wherein when the derived transaction is aborted, features and to belt transaction control program to be realized and derived restart control step of controlling a restart based on the derived start information stored in the derivation management DB.
前記ファイルが、
前記業務処理要求に関連した各種マスタＤＢと、
前記派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録すると共に当該派生管理通番が使用中であるか又は使用可であるかを示す使用中フラグを有する派生管理ＤＢと、
この派生管理ＤＢでの派生管理通番を前記各トランザクションのＪＯＢ番号を単位とした複数の派生管理通番から使用可の派生管理通番を特定すると共に前記派生管理通番が使用中であるか否かをビットのＯＮ又はＯＦＦにて示す派生インデックスビットを前記ＪＯＢ番号毎に複数有する派生インデックスＤＢとを備え、
前記演算手段が、
前記オンライントランザクション及び派生トランザクションを構成するプログラムの実行を管理する業務メイン処理部と、
この業務メイン処理部によって実行が管理されるプログラムを前記ＪＯＢ番号毎のトランザクションの一部として並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除する業務処理部とを備え、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記業務処理部は、前記端末から入力される業務処理要求をオンライントランザクションとして処理し、当該オンライントランザクションの処理結果を前記端末への応答として出力し、
前記業務メイン処理部は、前記派生トランザクションの起動を管理する派生要求共通処理と、前記派生トランザクションの開始及び完了を管理する派生特性管理共通処理と、前記派生トランザクションの完了の一部を管理する派生ＤＢ制御処理とを実行し、
前記派生要求共通処理は、前記派生起動トランザクションの原子性に包まれる処理として、前記プログラムの実行中に新たな派生トランザクションの派生起動要求依頼が出力された際に、当該派生起動トランザクションのＪＯＢ番号に応じて前記派生インデックスＤＢを参照し、前記派生管理ＤＢの派生管理通番を特定し、当該派生トランザクションの起動処理とは別に、当該派生管理通番のセグメントに当該派生起動情報を格納し、当該派生管理通番に対応する前記インデックスビット及び使用中フラグをそれぞれ使用中の状態に更新して、当該派生トランザクションを起動させることで、当該派生トランザクションの起動を管理し、業務メイン処理部は、当該起動後で当該派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせることで当該派生起動トランザクションのロックを解除し、当該ロック解除したデータ項目への他のトランザクションによるアクセスを許容し、
前記派生特性管理共通処理は、当該起動された派生トランザクションの原子性に包まれる処理として、当該派生トランザクションが起動され、当該派生トランザクションに与えられた派生管理通番をキー値とする派生管理ＤＢの読み込みに成功した際に、当該派生管理通番の使用中フラグが使用中である場合には、当該派生トランザクションの処理を実行させ、一方、当該使用中フラグが使用可である場合には、当該派生トランザクションをアボートすることで、当該派生トランザクションの開始を管理し、前記業務処理部は、当該派生トランザクションの処理を実行し、
当該派生特性管理処理は、当該派生トランザクションの原子性に包まれる処理として、当該派生トランザクションの処理が終了した後に、前記派生管理ＤＢの使用中フラグを使用可に更新して、前記派生ＤＢ制御処理を当該起動要求依頼された派生トランザクションとは別の派生トランザクションとして起動させ、この起動後に、当該派生トランザクションをコミットし、
前記派生ＤＢ制御処理は、前記派生ＤＢ制御処理がスケジュールされた場合に、当該派生管理通番に対応する前記派生インデックスＤＢの前記派生インデックスビットを使用可を示すＯＦＦへ更新することを特徴とするトランザクション制御システム。Receiving means for receiving a business processing request input via the end-terminal or the network from the number of JOB number predetermined on-line transactions and the predetermined derivative transactions in accordance with the business processing request received by the receiving means An arithmetic means for processing in parallel in units, and a file for recording the processing results of the arithmetic means,
The file is
Various master DBs related to the business processing request,
A derivation management DB having a use flag indicating whether the derivation management serial number is or usable either in use records the derived start information relating to the activation request request the derived transaction for each derivation management serial number,
The derivation management serial number in this derivation management DB is specified from a plurality of derivation management serial numbers in units of the JOB numbers of the respective transactions, and a bit indicating whether or not the derivation management serial number is in use. A derivation index DB having a plurality of derivation index bits indicated by ON or OFF of each JOB number;
The computing means is
And business main processing unit that manages the execution of programs constituting the online transaction and derived transaction,
A program whose execution is managed by the business main processing unit is executed in parallel as a part of the transaction for each JOB number, and when executing each transaction, the data item of each DB of the file is locked, Processing, recording the processing result in each DB of the file, and a business processing unit for releasing the lock after the recording ,
During the execution of each transaction, a transaction that outputs a request for starting a new transaction is referred to as a derived start transaction, and the transaction requested for the start request is a derived transaction.
The derived transaction is a transaction that occurs in association with the processing result of the online transaction and processes all or part of an incidental service that is not necessary for the response of the online transaction,
The business processing unit processes a business processing request input from the terminal as an online transaction, and outputs a processing result of the online transaction as a response to the terminal,
The business main processing unit includes a derivation request common process for managing the start of the derivation transaction, a derivation characteristic management common process for managing the start and completion of the derivation transaction, and a derivation for managing a part of the completion of the derivation transaction. DB control processing is executed,
The derivation request common process, as a process to be wrapped in atoms of the derivative start transaction, when the derived start request requesting a new derivative transactions during execution of the program is output, to JOB number of the derived activated transaction depending referring to the derived index DB, the specified derived management serial number of the derivation management DB, apart from the activation processing of the derived transaction, stores the derived start information to the segment of the derivative management serial number, those the derivative The index bit and the in-use flag corresponding to the raw management serial number are updated to the in-use state, and the derived transaction is activated to manage the activation of the derived transaction. The derived launch transaction without waiting for the start of the derived transaction after startup Deployment Unlock the derived start transaction by causing commit, allowing access by other transactions to the unlocked data item,
The derived characteristic management common process is a process included in the atomicity of the activated derived transaction, and the derived transaction DB is activated and the derived management DB is read using the derived management serial number given to the derived transaction as a key value. to upon successful, if busy flag of the derivation management serial number is in use, the processing of the derived transaction is executed. If the busy flag is usable is the By managing the start of the derived transaction by aborting the derived transaction, the business processing unit executes the process of the derived transaction,
The derived characteristic management process, as a process to be wrapped in atoms of the derivative transaction after the processing of the derived transaction is completed, updates the use flag of the derivation management DB to usable, the derivation DB control process Is activated as a derived transaction different from the derived transaction for which the activation request is requested, and after this activation, the derived transaction is committed,
The derivation DB control process, when the derived DB control process is scheduled, and wherein the benzalkonium updates the derivation index bits of the derived index DB corresponding to the derivation management serial number to be OFF to indicate usable to belt transaction control system.
前記派生ＤＢ制御処理機能が、前記派生管理通番から前記ビットマップ及びビット位置を算出することを特徴とする請求項１６記載のトランザクション制御システム。The derivation index DB holds the derivation index bits as a bitmap with the JOB number as a unit, and specifies the derivation management serial number at the bit position of the bitmap,
The derivation DB control processing function, transaction control system according to claim 16, wherein the calculating the bitmap and the bit position from the derivation management serial number.
前記ファイルが、
前記業務処理要求に関連した各種マスタＤＢと、
前記派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録すると共に当該派生管理通番が使用中であるか又は使用可であるか示す使用中フラグを有する派生管理ＤＢと、
この派生管理ＤＢでの派生管理通番を前記各トランザクションのＪＯＢ番号を単位とした複数の派生管理通番から使用可の派生管理通番を特定すると共に前記派生管理通番が使用中であるか否かを示す派生インデックスビットを前記ＪＯＢ番号毎に複数有する派生インデックスＤＢとを備え、
前記演算手段が、
前記オンライントランザクション及び派生トランザクションを構成するプログラムの実行を管理する業務メイン処理部と、
この業務メイン処理部によって実行が管理されるプログラムを前記ＪＯＢ番号毎のトランザクションの一部として並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除する業務処理部とを備えたオンラインシステムの前記演算手段を使用してトランザクションを管理するトランザクション制御方法であって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
派生起動トランザクションの起動を管理すると共に当該派生起動トランザクションによって起動要求依頼される派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせることで当該派生起動トランザクションのロックを解除し、当該ロック解除したデータ項目への他のトランザクションによるアクセスを許容する派生起動トランザクション管理工程と、
前記派生起動トランザクションによって起動要求依頼された派生トランザクションの開始及び管理を管理する派生トランザクション管理工程と、
この派生トランザクション管理工程にて派生トランザクションとして起動される派生ＤＢ管理工程とを備え、
前記派生起動トランザクション管理工程は、当該派生起動トランザクションの原子性に包まれる処理として、当該派生起動トランザクションのＪＯＢ番号に応じて前記派生インデックスＤＢを参照し、前記派生管理ＤＢの派生管理通番を特定し、当該派生トランザクションの起動処理とは別に、当該派生管理通番のセグメントに派生起動情報を格納し、当該使用した派生管理通番に対応する前記インデックスビット及び使用中フラグをそれぞれ使用中の状態に更新して、当該派生トランザクションを起動させることで、当該派生トランザクションの起動を管理する派生要求共通処理工程を備え、
前記派生トランザクション管理工程は、当該起動された派生トランザクションの原子性に包まれる処理として、当該派生トランザクションが起動されスケジュールされ、当該派生トランザクションに与えられた派生管理通番をキー値とする派生管理ＤＢの読み込みに成功した際に、当該派生管理通番の使用中フラグが使用中である場合には当該派生トランザクションの処理を実行させ、一方、当該使用中フラグが使用可である場合には、当該派生トランザクションをアボートすることで、当該派生トランザクションの開始を管理し、
当該派生トランザクションの処理が終了した後に、前記派生管理ＤＢの使用中フラグを使用可に更新して、さらに所定の派生ＤＢ制御処理を派生トランザクションとして起動させ、この起動後に、当該派生トランザクションをコミットする派生特性管理共通処理工程を備え、
前記派生ＤＢ管理工程は、前記派生ＤＢ制御処理がスケジュールされた場合に、当該派生管理通番に対応する前記派生インデックスＤＢの前記派生インデックスビットを使用可を示すＯＦＦに更新する派生ＤＢ制御処理工程を備えたことを特徴とするトランザクション制御方法。Receiving means for receiving a business processing request input via the end-terminal or the network from the number of JOB number predetermined on-line transactions and the predetermined derivative transactions in accordance with the business processing request received by the receiving means An arithmetic means for processing in parallel in units, and a file for recording the processing results of the arithmetic means,
The file is
Various master DBs related to the business processing request,
A derivation management DB also whether the derivation management serial number is in use with a use flag indicating whether the usable records the derived start information relating to the activation request request the derived transaction for each derivation management serial number,
The derivation management serial number in the derivation management DB is specified from a plurality of derivation management serial numbers in units of the JOB numbers of the respective transactions, and an available derivation management serial number is indicated, and whether or not the derivation management serial number is in use is indicated. A derived index DB having a plurality of derived index bits for each JOB number;
The computing means is
A business main processing unit that manages execution of a program constituting the online transaction and the derived transaction;
A program whose execution is managed by the business main processing unit is executed in parallel as a part of the transaction for each JOB number, and when executing each transaction, the data item of each DB of the file is locked, processing, the processing result is recorded in each DB of the file, belt La to manage transactions using the arithmetic means of the online system and a business processing unit to release the lock after the recording A transaction control method,
During the execution of each transaction, a transaction that outputs a request for starting a new transaction is referred to as a derived start transaction, and the transaction requested for the start request is a derived transaction.
The derived transaction is a transaction that occurs in association with the processing result of the online transaction and processes all or part of an incidental service that is not necessary for the response of the online transaction,
Manages the activation of a derivative activation transaction and releases the lock of the derivative activation transaction by committing the derivative activation transaction without waiting for the start of the derivative transaction requested for activation by the derivative activation transaction. Derived start transaction management process that allows access by other transactions to the selected data item ;
A derivative transaction management process for managing the start and management of a derivative transaction requested to be activated by the derivative activation transaction;
A derivation DB management process activated as a derivation transaction in this derivation transaction management process,
In the derivative activation transaction management step, as a process included in the atomicity of the derivative activation transaction, the derivative index DB is referred to according to the job number of the derivative activation transaction, and the derivative management serial number of the derivative management DB is specified. Separately from the activation process of the derived transaction , the derivative activation information is stored in the segment of the derivative management serial number, and the index bit and the in-use flag corresponding to the used derivative management serial number are respectively updated to the in-use state. Te, in Rukoto activates the derived transaction, comprising the derived requirements common processing step of managing the activation of the derived transaction,
The derivation transaction management process, as a process to be wrapped in atoms of the invoked derived transactions, the derived transaction is scheduled is activated, the derivation management DB for the derivation management serial number given to the derived transaction key value upon successful loading, to execute the processing of the derived transaction if busy flag of the derivation management serial number is in use, on the other hand, when the busy flag is usable is the derived transaction To control the start of the derived transaction,
After processing of the derived transaction is completed, the update of the use flag of the derived management DB in usable, and further activates a predetermined derivation DB control process as a derivative transaction, after the activation, to commit the derived transaction Derived characteristic management common processing process
The derivation DB management step includes a derivation DB control processing step of updating the derivation index bit of the derivation index DB corresponding to the derivation management serial number to OFF indicating that the derivation DB control processing is scheduled, when the derivation DB control processing is scheduled. transaction control method characterized by comprising.
前記ファイルが、
前記業務処理要求に関連した各種マスタＤＢと、
前記派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録すると共に当該派生管理通番が使用中であるか又は使用可であるか示す使用中フラグを有する派生管理ＤＢと、
この派生管理ＤＢでの派生管理通番を前記各トランザクションのＪＯＢ番号を単位とした複数の派生管理通番から使用可の派生管理通番を特定すると共に前記派生管理通番が使用中であるか否かを示す派生インデックスビットを前記ＪＯＢ番号毎に複数有する派生インデックスＤＢとを備え、
前記演算手段が、
前記オンライントランザクション及び派生トランザクションを構成するプログラムの実行を管理する業務メイン処理部と、
この業務メイン処理部によって実行が管理されるプログラムを前記ＪＯＢ番号毎のトランザクションの一部として並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除する業務処理部とを備え、
前記演算手段に所定の工程を実現させるためのトランザクション制御プログラムであって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
派生起動トランザクションの起動を管理すると共に当該派生起動トランザクションによって起動要求依頼される派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせることで当該派生起動トランザクションのロックを解除し、当該ロック解除したデータ項目への他のトランザクションによるアクセスを許容する派生起動トランザクション管理工程と、
前記派生起動トランザクションによって起動要求依頼された派生トランザクションの開始及び管理を管理する派生トランザクション管理工程と、
この派生トランザクション管理工程にて起動要求依頼された派生トランザクションとは別の派生トランザクションとして起動される派生ＤＢ管理工程とを前記演算手段に実現させ、
前記派生起動トランザクション管理工程の一部として、当該派生起動トランザクションの原子性に包まれる処理として、当該派生起動トランザクションのＪＯＢ番号に応じて前記派生インデックスＤＢを参照し、前記派生管理ＤＢの派生管理通番を特定し、当該派生トランザクションの起動処理とは別に、当該派生管理通番のセグメントに派生起動情報を格納し、当該使用した派生管理通番に対応する前記インデックスビット及び使用中フラグをそれぞれ使用中の状態に更新して、当該派生トランザクションを起動させることで、当該派生トランザクションの起動を管理する派生要求共通処理工程を実現させ、
前記派生トランザクション管理工程の一部として、当該起動された派生トランザクションの原子性に包まれる処理として、当該派生トランザクションが起動されスケジュールされ、当該派生トランザクションに与えられた派生管理通番をキー値とする派生管理ＤＢの読み込みに成功した際に、当該派生管理通番の使用中フラグが使用中である場合には当該派生トランザクションの処理を実行させ、一方、当該使用中フラグが使用可である場合には、当該派生トランザクションをアボートすることで、当該派生トランザクションの開始を管理し、
当該派生トランザクションの処理が終了した後に、前記派生管理ＤＢの使用中フラグを使用可に更新して、さらに所定の派生ＤＢ制御処理を派生トランザクションとして起動させ、この起動後に、当該派生トランザクションをコミットする派生特性管理共通処理工程を実現させ、
前記派生ＤＢ管理工程の一部として、前記派生ＤＢ制御処理がスケジュールされた場合に、当該派生管理通番に対応する前記派生インデックスＤＢの前記派生インデックスビットを使用可を示すＯＦＦに更新する派生ＤＢ制御処理工程を実現させることを特徴とするトランザクション制御プログラム。Receiving means for receiving a business processing request input via the end-terminal or the network from the number of JOB number predetermined on-line transactions and the predetermined derivative transactions in accordance with the business processing request received by the receiving means An arithmetic means for processing in parallel in units, and a file for recording the processing results of the arithmetic means,
The file is
Various master DBs related to the business processing request,
A derivation management DB also whether the derivation management serial number is in use with a use flag indicating whether the usable records the derived start information relating to the activation request request the derived transaction for each derivation management serial number,
The derivation management serial number in the derivation management DB is specified from a plurality of derivation management serial numbers in units of the JOB numbers of the respective transactions, and an available derivation management serial number is indicated, and whether or not the derivation management serial number is in use is indicated. A derived index DB having a plurality of derived index bits for each JOB number;
The computing means is
A business main processing unit that manages execution of a program constituting the online transaction and the derived transaction;
The program to be executed is managed by the business main processing unit is performed in parallel as part of the transaction for each of the JOB number, upon execution of each transaction, respectively, to lock the data item of each DB of the file A processing unit for processing, recording the processing result in each DB of the file, and releasing the lock after the recording,
A transaction control program for realizing a predetermined process to the arithmetic means,
During the execution of each transaction, a transaction that outputs a request for starting a new transaction is referred to as a derived start transaction, and the transaction requested for the start request is a derived transaction.
The derived transaction is a transaction that occurs in association with the processing result of the online transaction and processes all or part of an incidental service that is not necessary for the response of the online transaction,
Manages the activation of a derivative activation transaction and releases the lock of the derivative activation transaction by committing the derivative activation transaction without waiting for the start of the derivative transaction requested for activation by the derivative activation transaction. Derived start transaction management process that allows access by other transactions to the selected data item ;
A derivative transaction management process for managing the start and management of a derivative transaction requested to be activated by the derivative activation transaction;
The calculation means realizes a derivation DB management process that is activated as a derivation transaction different from the derivation transaction requested in the derivation transaction management process,
As a part of the derivative activation transaction management process, as a process included in the atomicity of the derivative activation transaction, the derivation management DB is referred to according to the JOB number of the derivative activation transaction, and the derivation management serial number of the derivation management DB Separately from the activation process of the derived transaction , the derivative activation information is stored in the segment of the derivative management serial number, and the index bit and the in-use flag corresponding to the used derivative management serial number are in use. update, in Rukoto activates the derived transaction, to realize the derived requirements common processing step of managing the activation of the derived transaction,
As part of the derivation transaction management process, as a process to be wrapped in atoms of the invoked derived transactions, derived in which the derived transaction is scheduled is activated, the derivation management serial number given to the derived transaction key value When the management database is successfully read , if the in-use flag of the derivation management serial number is in use, the processing of the derivation transaction is executed, while if the in-use flag is usable, Abort the derived transaction to manage the start of the derived transaction,
After processing of the derived transaction is completed, the update of the use flag of the derived management DB in usable, and further activates a predetermined derivation DB control process as a derivative transaction, after the activation, to commit the derived transaction To realize the common processing process
Derived DB control that updates the derived index bit of the derived index DB corresponding to the derived management serial number to OFF indicating that the derived DB control process is scheduled as part of the derived DB management process. transaction control program, characterized in that to realize the process.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001143203A JP3732113B2 (en) | 2001-05-14 | 2001-05-14 | Transaction control system, method and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001143203A JP3732113B2 (en) | 2001-05-14 | 2001-05-14 | Transaction control system, method and program |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002342138A JP2002342138A (en) | 2002-11-29 |
| JP3732113B2 true JP3732113B2 (en) | 2006-01-05 |
Family
ID=18989382
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001143203A Expired - Lifetime JP3732113B2 (en) | 2001-05-14 | 2001-05-14 | Transaction control system, method and program |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3732113B2 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010134437A1 (en) | 2009-05-18 | 2010-11-25 | Nishiyama Shuhei | Meta-information sharing distributed database system in virtual single memory storage |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4555624B2 (en) * | 2004-07-29 | 2010-10-06 | 新日鉄ソリューションズ株式会社 | Data processing system, data processing method and program thereof |
| JP5011728B2 (en) * | 2006-01-11 | 2012-08-29 | 日本電気株式会社 | System adopting hot standby method and synchronization method used therefor |
| JP2008097476A (en) * | 2006-10-16 | 2008-04-24 | Hitachi Ltd | Batch system of sequential processing mode |
| US7899999B2 (en) * | 2007-06-27 | 2011-03-01 | Microsoft Corporation | Handling falsely doomed parents of nested transactions |
| JP2009020765A (en) * | 2007-07-12 | 2009-01-29 | Hitachi Computer Peripherals Co Ltd | Read/write method and computer system using the read/write method |
| US7890472B2 (en) | 2007-09-18 | 2011-02-15 | Microsoft Corporation | Parallel nested transactions in transactional memory |
| JP5086934B2 (en) * | 2008-08-07 | 2012-11-28 | 株式会社三菱東京Ｕｆｊ銀行 | Data processing apparatus and program |
| JP4462504B1 (en) * | 2009-09-23 | 2010-05-12 | 修平 西山 | A multi-transaction control system with update access counters owned by the transaction process that is the starting point for maintaining consistency |
| JP5295395B2 (en) * | 2012-01-04 | 2013-09-18 | 株式会社三菱東京Ｕｆｊ銀行 | Data processing device |
| JP5604554B2 (en) * | 2013-04-30 | 2014-10-08 | 株式会社三菱東京Ｕｆｊ銀行 | Data processing device |
| CN116993505B (en) * | 2023-09-25 | 2024-01-16 | 腾讯科技（深圳）有限公司 | Transaction processing method, device, electronic equipment and storage medium |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH02118841A (en) * | 1988-10-28 | 1990-05-07 | Nec Corp | Input queue control system |
| JPH0792788B2 (en) * | 1989-02-14 | 1995-10-09 | 日本電気株式会社 | Transaction message output control method |
| JP2817773B2 (en) * | 1995-02-06 | 1998-10-30 | 日本電気株式会社 | Method for detecting program loops across transactions |
| JP3672208B2 (en) * | 1996-07-02 | 2005-07-20 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Hierarchical transaction processing method |
| US7184988B1 (en) * | 1999-01-28 | 2007-02-27 | Certco, Inc. | Methods for operating infrastructure and applications for cryptographically-supported services |
| JP3471728B2 (en) * | 2000-08-10 | 2003-12-02 | 株式会社八十二銀行 | Future date completion processing system and method |
| JP3611110B2 (en) * | 2001-03-19 | 2005-01-19 | 株式会社八十二銀行 | System, method and program for completion process of the previous date, program for cancel / recut main process used therefor, resource optimization system, program and program for cancel / reexecute main process used therefor |
-
2001
- 2001-05-14 JP JP2001143203A patent/JP3732113B2/en not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010134437A1 (en) | 2009-05-18 | 2010-11-25 | Nishiyama Shuhei | Meta-information sharing distributed database system in virtual single memory storage |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002342138A (en) | 2002-11-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7380166B2 (en) | Compensation framework for long running transactions | |
| US7103597B2 (en) | Adaptive transaction manager for complex transactions and business process | |
| US6275863B1 (en) | System and method for programming and executing long running transactions | |
| CN101495976B (en) | Direct-update software transactional memory | |
| US20040158549A1 (en) | Method and apparatus for online transaction processing | |
| US6625602B1 (en) | Method and system for hierarchical transactions and compensation | |
| EP2550632B1 (en) | System with multiple conditional commit databases | |
| US9805088B2 (en) | Constraint-based consistency with snapshot isolation | |
| JP3732113B2 (en) | Transaction control system, method and program | |
| US6061708A (en) | System and method for supporting mixed-phase transactions in an object-oriented environment | |
| US20090077135A1 (en) | Framework for handling business transactions | |
| JP3512439B2 (en) | Locking method in check-in / check-out model | |
| US20020178395A1 (en) | Multi-agent cooperative transaction method and system | |
| US6389431B1 (en) | Message-efficient client transparency system and method therefor | |
| JP2011003200A (en) | Method and system for managing long running transaction | |
| Frank | Evaluation of the basic remote backup and replication methods for high availability databases | |
| CN104765645B (en) | Merge the method and system of conventional computer system in Service Orientation Architecture | |
| JP3611110B2 (en) | System, method and program for completion process of the previous date, program for cancel / recut main process used therefor, resource optimization system, program and program for cancel / reexecute main process used therefor | |
| US20060294006A1 (en) | Business transaction process controller for composite transactions | |
| JP3471728B2 (en) | Future date completion processing system and method | |
| JP3903471B2 (en) | Complete processing system with date and time | |
| US8108273B2 (en) | Replicating data in financial systems | |
| JPH10232809A (en) | Transaction processing system | |
| JP3941946B2 (en) | A recording medium recording a program for completion processing of a previous date and a program for canceling / recutting main processing | |
| Frank | Atomicity implementation in mobile computing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050214 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050414 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051011 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051011 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3732113 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111021 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20141021 Year of fee payment: 9 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |