JP3732113B2 - トランザクション制御システム、方法及びプログラム - Google Patents
トランザクション制御システム、方法及びプログラム 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
- 238000000034 method Methods 0.000 title claims description 435
- 238000007726 management method Methods 0.000 claims description 454
- 238000012545 processing Methods 0.000 claims description 447
- 238000001994 activation Methods 0.000 claims description 422
- 238000009795 derivation Methods 0.000 claims description 417
- 230000004913 activation Effects 0.000 claims description 414
- 230000008569 process Effects 0.000 claims description 404
- 230000006870 function Effects 0.000 claims description 110
- 230000004044 response Effects 0.000 claims description 80
- 238000003860 storage Methods 0.000 claims description 33
- 238000012544 monitoring process Methods 0.000 claims description 23
- 238000004364 calculation method Methods 0.000 claims description 21
- 206010000210 abortion Diseases 0.000 claims description 19
- 230000003213 activating effect Effects 0.000 claims description 7
- 230000014759 maintenance of location Effects 0.000 claims description 3
- 238000004148 unit process Methods 0.000 claims description 2
- 229960001716 benzalkonium Drugs 0.000 claims 1
- CYDRXTMLKJDRQH-UHFFFAOYSA-N benzododecinium Chemical compound CCCCCCCCCCCC[N+](C)(C)CC1=CC=CC=C1 CYDRXTMLKJDRQH-UHFFFAOYSA-N 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 54
- 238000012546 transfer Methods 0.000 description 38
- 230000004043 responsiveness Effects 0.000 description 29
- 239000002253 acid Substances 0.000 description 18
- 238000004891 communication Methods 0.000 description 17
- 230000005611 electricity Effects 0.000 description 16
- 230000000737 periodic effect Effects 0.000 description 14
- 238000010923 batch production Methods 0.000 description 11
- 230000008859 change Effects 0.000 description 9
- 230000007246 mechanism Effects 0.000 description 9
- 238000012937 correction Methods 0.000 description 8
- 230000008521 reorganization Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 238000010924 continuous production Methods 0.000 description 4
- 238000005520 cutting process Methods 0.000 description 4
- 238000002955 isolation Methods 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 102220575589 Synaptotagmin-13_S97A_mutation Human genes 0.000 description 3
- 239000000872 buffer Substances 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000011084 recovery Methods 0.000 description 3
- 102220057255 rs730881172 Human genes 0.000 description 3
- 102220537827 Nebulette_S17A_mutation Human genes 0.000 description 2
- 102220478717 Scinderin_S98A_mutation Human genes 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 230000006866 deterioration Effects 0.000 description 2
- 230000002542 deteriorative effect Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000007420 reactivation Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 239000000725 suspension Substances 0.000 description 2
- 238000012384 transportation and delivery Methods 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 241000272808 Anser Species 0.000 description 1
- 101100160804 Bacillus subtilis (strain 168) yxaD gene Proteins 0.000 description 1
- 101001074449 Crotalus durissus terrificus Phospholipase A2 inhibitor CNF Proteins 0.000 description 1
- 102220537824 Nebulette_S99A_mutation Human genes 0.000 description 1
- 230000004308 accommodation Effects 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000000151 deposition Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000001627 detrimental effect Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000009931 harmful effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000010561 standard procedure Methods 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
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）を意味する。先入れ先出し方式の略語としては用いない。ＦＩＦＯは、ＩＭＳ／ＥＳＡオンライン適用業務開発／運用支援プログラムであるＳＡＩＬによって提供される抽象化である。端末等からの全ての入力は、その業務に応じてＦＩＦＯという情報域に編集され、セットされる。このため、適用業務プログラムは、端末等から入力の形式によらず、予め定義したＦＩＦＯでの位置に特定の項目のデータがセットされている前提で開発することができる。すなわち、ＦＩＦＯを用いることで、入出力メッセージの形式によらず、適用業務プログラムを開発することができる。入出力メッセージとＦＩＦＯとは、編集定義を用いて関連させる。例えば、派生起動トランザクションが派生トランザクションを起動する場合には、派生トランザクションの実行に必要なデータをＦＩＦＯにセットし、派生起動要求依頼を行う。すると、ＳＡＩＬは、派生編集番号に従ってＦＩＦＯから派生メッセージを生成する。端末からの業務処理要求の入力や、端末への出力メッセージについても同様に業務毎の編集定義を用いる。
【０１２８】
図１０は、ＪＯＢ番号と、派生インデックスＤＢ６８のインデックス領域番号８８と、ビット位置と、符号８９で示す派生管理通番との関係を例示する説明図である。図１０（Ａ）に示すように、ＪＯＢ番号０００で実行されているトランザクションによって読み出されるインデックス・ビットマップの番号（インデックス領域番号）は、「０００」である。図１０（Ａ）に示す例では、ビット位置１及び５が使用中である。この場合、派生管理ＤＢの内容は図１０（Ｂ）に示す如くとなる。派生起動トランザクション側では、インデックス・ビットマップのビット（派生インデックスビットと呼ぶ）と、使用中フラグとは、原子性に包まれていることが望ましい。
【０１２９】
図１０（Ｃ）及び（Ｄ）に示すように、１つのインデックス・ビットマップが特定する派生管理通番の数Ｍが定められていると、インデックス領域番号８８とビット位置とに基づいて派生管理通番を特定することができる。
【０１３０】
図１１は、派生トランザクションの要求を管理するための派生要求管理処理の一例を示すフローチャートである。図１２は、派生トランザクションの特性を管理するための派生特性管理処理の一例を示すフローチャートである。図１１に示す派生要求共通処理は、派生起動トランザクションの一部として実行される。図１２に示す派生特性管理共通処理は、派生トランザクションの一部として、または別の処理として実行する。
【０１３１】
図１１を参照すると、派生要求共通処理は、派生起動トランザクションから派生起動要求依頼を受けると、まず、そのＪＯＢ番号（すなわち、インデックス領域番号）をキー値として派生インデックスＤＢを読み込む（ステップＳ５２）。そして、インデックス領域番号での残り個数フィールドをチェックし（ステップＳ５２）、空きがあれば、インデックス・ビットマップから空き（インデックスビットが０）のビット位置を特定する。ステップＳ５２にて空きが無い場合には、予備の派生インデックスＤＢを読み込み、残り個数フィールドをチェックする（ステップＳ６２）。予備の派生管理通番まで使用中である場合には、異常終了する。
【０１３２】
空きの派生インデックスビットを特定すると、そのビット位置に基づいて派生管理通番を算出する。そして、この派生管理通番を派生起動トランザクションが動作しているリージョンのＦＩＦＯにセットする。さらに、派生インデックスビットをＯＮ（対応する派生管理通番が使用中）を示す「１」に更新する（ステップＳ５４）。
【０１３３】
続いて、派生管理通番をキー値として、派生管理ＤＢを読み込み（ステップＳ５５）、派生インデックスＤＢ６８の残り個数フィールドと、派生件数フィールドとを更新する（ステップＳ５６）。そして、派生管理ＤＢに派生起動情報を登録し、派生管理ＤＢ７０の使用中フラグを「使用中」とする（ステップＳ５７）。続いて、派生トランザクションの起動を制御する（ステップＳ５８）。例えば、ＳＡＩＬは、派生起動トランザクションのＦＩＦＯから派生メッセージを生成し、待ち行列に登録する。続いて、派生起動トランザクションはコミットする。
【０１３４】
図１２は、派生トランザクションの開始及び終了時等の処理を示すフローチャートである。派生特性管理共通処理では、まず、派生トランザクションがいずれかのリージョンにスケジュールされると、まず、派生起動メッセージの派生管理通番をキー値として派生管理ＤＢ７０を読み込む。派生起動トランザクションがコミットしていない段階では、派生管理ＤＢ７０の当該派生管理通番のセグメントはロックされているため、ステップＳ７１では、派生起動トランザクションがコミット又はアボートし、このロックが解除されるまで待機する。
【０１３５】
派生トランザクションは、派生管理ＤＢの内容の読み出しに成功すると、まず、使用中フラグをチェックする。使用中フラグは、派生起動トランザクションによってステップＳ５７によって使用中を示す１に更新にされている。派生起動トランザクションがコミットした場合、この使用中フラグは「使用中」のままである。一方、派生起動トランザクションがステップＳ５８以後にアボートした場合、ロールバックによって、派生起動トランザクションによる使用中フラグの「使用中」への更新が取り消され、使用中フラグは使用可を示す０となっている。従って、ステップＳ７２では、使用中フラグが使用可の場合には、派生起動トランザクションがコミットした場合にのみ派生トランザクションがコミットするという派生トランザクションの性質に従って、派生トランザクションの適用業務プログラムを実行せずに終了する（ステップＳ７４）。
【０１３６】
派生起動トランザクションが正常にコミットしている場合、使用中フラグは「使用中」であるため、派生トランザクションの適用業務プログラムを呼び出し、実行を制御する（ステップＳ７５）。この適用業務プログラムの実行が完了すると、派生特性管理共通処理では、派生管理通番をキーとして派生管理ＤＢを読み込む（ステップＳ７６）。そして、使用中フラグを使用可に更新する（ステップＳ７７）。このとき、派生インデックスＤＢの派生インデックスビットも使用中のままとなっている。このため、派生トランザクションの一部として、又は別のトランザクションを用いて、派生インデックスＤＢ７８の派生インデックスビットをオフに更新する。この派生インデックスビットの更新に前後して、派生トランザクションはコミットする。
【０１３７】
また、図１２に示す派生特性管理共通処理によってその特性が管理される派生トランザクションが、別の派生トランザクションを起動する場合には、この派生トランザクションをコミットさせる前に、図１１に示す処理を実行する。
【０１３８】
ここで、図７に示す各機能と、図１１及び図１２に示す各工程との関係を説明する。図７に示すトランザクション管理システムの各機能１０１，１０２，１０３，１０４，１０５，１０６は、第１実施形態の場合と同様に、ＣＰＵが、派生管理通番特定機能１０１を実現するための派生管理通番特定指令や、派生起動情報格納制御指令などを実行することで実現できる。
【０１３９】
例えば、このプログラムは、オンライントランザクション又は派生トランザクションである派生起動トランザクションから派生トランザクションの起動要求依頼があったときに前記派生インデックスＤＢのインデックス情報を特定させると共に当該特定したインデックス情報に基づいて前記派生管理ＤＢの使用可の派生管理通番を特定させる派生管理通番特定指令を備えている。この指令を実行すると、ＣＰＵは派生管理通番特定機能１０１として動作する。図１１に示す例では、この派生管理通番特定指令を実行すると、ＣＰＵはステップＳ５１，５２，Ｓ５３及びＳ５４等の工程を実現する。
【０１４０】
また、このプログラムは、派生管理通番特定指令に応じて特定された派生管理通番のセグメントに前記派生起動トランザクションによる派生トランザクションの起動要求依頼に関する派生起動情報を格納させると共に当該派生起動情報を格納した後に当該派生トランザクションを起動させる派生起動情報格納制御指令を備える。ＣＰＵは、この指令を実行することで派生起動情報格納機能１０２として動作する。図１１に示す例では、ステップＳ５４，Ｓ５５，Ｓ５６，Ｓ５７の工程を処理する。
【０１４１】
プログラムは、さらに、派生起動情報の格納後で当該派生起動トランザクションの各処理が正常終了した場合に当該派生起動トランザクションをコミットさせる派生起動トランザクションコミット処理指令を備える。これにより、ＣＰＵは、派生起動トランザクションコミット処理機能１０３として動作する。ステップＳ１１では、最後の工程である。
【０１４２】
また、プログラムは、前記派生トランザクションの開始時に前記派生起動情報をロック可能な状態での正常な読み出しに成功した場合に当該派生トランザクションの各処理を開始させる直列性制御指令を備える。図１２に示す例では、これは、ステップＳ１２の派生起動情報の読み取り工程Ｓ７１によって、この直列性の制御を実現する。直列性制御指令を実行するＣＰＵは、直列性制御機能１０４として、図１２に示すステップＳ７１からＳ７５の処理を行う。
【０１４３】
派生トランザクション管理用プログラムはさらに、派生トランザクションの各処理が正常終了した場合に使用した派生管理通番について前記派生インデックスＤＢ及び前記派生管理ＤＢを使用可に更新させると共に当該派生トランザクションをコミットさせる派生トランザクションコミット処理指令を備える。この指令を実行するＣＰＵは、派生トランザクションコミット処理機能１０５として、図１２に示すＳ７６，Ｓ７７，Ｓ７８，Ｓ７９の処理を行う。第３実施形態では、デッドロックの発生を防止するために、派生トランザクションとは別のトランザクションとしてＳ７８及びＳ７９による派生インデックスＤＢの更新を行う。
【０１４４】
また、このプログラムは、派生トランザクションがアボートされた場合には前記派生管理ＤＢに格納した派生起動情報に基づいた再起動を制御する派生再起動制御指令を備える。この派生再起動制御指令を実行するＣＰＵは、派生再起動制御機能１０６として機能する。実際の再起動処理は、派生再起動制御部７７が行うようにしても良い。このように、図７に示す各部や図１１，図１２等のフローチャートに示す各工程は、それぞれの処理を行うプログラムを実行することによって実現できる。これは、総量制御処理や（図１９）、派生再起動要否判定処理（図２２）や、派生再起動制御処理（図２３）の各フローチャートに示す工程についても同様である。
【０１４５】
このように、図１１及び図１２に示す例では、派生インデックスＤＢ６８が、前記インデックス領域番号８８毎のビットマップを派生インデックスビットの列として有すると共に、当該派生インデックスビットのＯＮ又はＯＦＦに応じて当該ビットのビット位置に対応する派生管理ＤＢ７０の使用状態を記録している。そして、派生管理ＤＢ７０は、派生管理通番毎に当該派生管理通番の使用状態を使用中又は使用可として記録する使用中フラグを有する。
【０１４６】
さらに、派生管理通番特定機能１０１は、使用可を示すＯＦＦ（０）の派生インデックスビット及び使用可（０）の派生管理通番を特定したときに、当該派生インデックスビットについて使用中を示すＯＮ（１）へと更新する（ステップＳ５４）。続いて、派生起動情報格納制御機能１０２は、派生起動情報を格納したときに当該派生管理通番の使用中フラグについて使用中（１）へと更新する（ステップＳ５７）。そして、直列性制御機能１０４は、前記派生起動トランザクションから渡された派生管理通番の使用中フラグが使用可（０）であった場合には当該起動要求されている派生トランザクションを起動せずに処理を終了させ（ステップＳ７４）、派生トランザクションコミット制御機能１０５は、当該派生トランザクションの完了時又は完了後に前記派生インデックスビット及び前記使用中フラグについて使用可の状態（０）へと更新する（ステップＳ７７，Ｓ７９）。すなわち、派生インデックスビットをＯＦＦ（０）とし、使用中フラグを使用可（０）とする。
【０１４７】
このように、派生起動トランザクションと派生トランザクション間の派生起動情報のコンテンションを利用することで、派生トランザクションの性質を一般的なＤＢのロック機構を用いて実現することができる。
【０１４８】
次に、先日付完結処理システムでの取消再カットメインを例として派生トランザクション管理の一例を説明する。
トランザクションのコミットのタイミングをプログラム中に記述しない方が、そのプログラムの再利用性は高まる。このため、トランザクションの実行を管理するプログラムが、適用業務プログラム（ＡＰＰＬ）を呼び出し、実行し、正常に終了した段階でコミットを与える仕組みとすると、ＡＰＰＬを種々の態様で利用することができる。トランザクションの管理を行うプログラムを、ここでは業務メインと呼ぶ。また、ＡＰＰＬの実行形態として、端末から初回に入力された場合や、連続して繰り返し処理する場合や、連動処理として呼び出された場合や、派生トランザクションとして起動された場合や、センター一括処理として入力される場合などがある。これらの取引の態様が異なっても、プログラムの一部または全体が共通する場合がある。このため、プログラムを細分化しておき、起動の形態に応じて適切なプログラムを特定する仕組みとすると、プログラムの再利用性が高まり、全体の行数を少なくすることができる。
【０１４９】
図１３は、このような仕組みを提供するためのオペコードテーブルの一例を示す説明図である。業務処理要求や、派生トランザクションの内容は、オペコードで特定される。例えば、普通預金の出金処理のオペコードは０１００１である。そして、端末初回入力の場合には、プログラム０１，０２，０３をこの順に呼び出して実行する。同様に、連動処理の依頼を受けた場合には、プログラム０６，０７，０８をこの順に実行する。ＳＡＩＬは、業務処理要求（オペコードを含む）を受信すると、その業務に応じた編集定義を特定し、編集定義に基づいてＦＩＦＯを組み立てると共に、業務メインを呼び出す。業務メインは、オペコードテーブルのプログラムリストに従ってプログラム（ＡＰＰＬ）を呼び出す。
【０１５０】
さらに、業務メインは、派生トランザクションの起動要求依頼を受けた場合には、図１１に示す処理を実行するプログラムを呼び出す。一方、派生トランザクションの起動に際しては、派生トランザクションのオペコードによるＡＰＰＬの呼び出しの前後に、図１２に示す処理を実行する。
【０１５１】
図１３に示すように、普通預金出金のオペコードは、０１００１である。先日付完結処理システムでは、この普通預金出金は取り消されることがある。この取消については、すべてのオペコードについて一定値（図１３に示す例では、５００）を加算する体系としている。これにより、ある取引を取り消す場合にオペコードを探索する必要がなくなる。図１３に示すように、普通預金の出金は、定積入金（０３００１）や、定期入金（０４００１）から連動起動又は派生起動なされる。
【０１５２】
図１４は、取消再カットメインでの処理例を示す説明図であり、図１４（Ａ）は口座処理による電気料引落（内部自振）の取消を行う例を示す図で、図１４（Ｂ）はその処理による残高の推移を示す図である。図１４（Ｂ）に示すように、６日の残高が６０，０００で、７日を勘定日とした電気料の引落（自振通番１２３４５）２０，０００が先日付完結処理により実行され、７日の残高が４０，０００となっているとする。この状態で、ＡＴＭを用いて普通預金から定期預金への入金があると、定期入金処理Ｓ２１は、オペコード０１００１の普通預金出金Ｓ２２を連動起動する。普通預金出金では、６日の残高は６０，０００であるため、５０，０００の出金が可能であることから、５０，０００の出金を行い、成立した旨を定期入金に伝える（連動戻り）。
【０１５３】
定期入金では定期預金マスタ等に記録し、ＡＴＭに定期入金が完了した旨の応答を出力する。一方、普通預金出金Ｓ２２では、６日の残高の更新後に、先日付の勘定日である７日の残高も更新する。７日の残高は、マイナス１０，０００となる。普通預金出金Ｓ２２は、７日の残高がマイナスとなったことから、７日を勘定日として取消再カットメインを起動する。取消再カットメインは、出金可能額のマイナスが解消するまで７日にて成立している口座処理を取り消す制御をする。ここでは、電気料の引落を取り消しを起動する。ステップＳ２４では、電気料の引落の取消（オペコード０２００１＋５００＝０２５０１）を行い、普通出金の取消に連動する。普通出金の取消（オペコード０１００１＋５００＝０１５０１）は、２０，０００の出金の取消を行うため、７日の残高に２０，０００を加算する。そして、７日の口座残高に異動が生じたため、再度取消再カットメインを派生トランザクションとして起動する。取消再カットメインＳ２６は、図４に示す処理を行い、取消再カットの必要性がないことから、なんら起動せずに処理を終了する。
【０１５４】
図１４（Ａ）に示すように、定期入金と普通出金は連動しており、１つのトランザクションＴ１である。これが、リージョン０にスケジュールされ、ＪＯＢ番号が「０００」であるとする。普通出金が派生トランザクションの起動要求依頼をしたとき、トランザクションＴ１はコミットしていない。高速パス（ＦＰ）を用いたシステムでは、トランザクションＴ１のコミットの前に派生トランザクションがスケジュールされる。リージョン０は派生起動トランザクションＴ１によって使用されているため、派生トランザクションである取消再カットメインは、例えばリージョン１にスケジュールされる。この場合、取消再カットメインのＪＯＢ番号は「００１」となる。取消再カットメインＳ２３は、種々の判定処理を行った後に電気料引落の取消を派生トランザクションとして起動する。
【０１５５】
取消再カットメインＳ２３が派生起動トランザクションＴ２として電気料引落の取消処理を起動させたとき、定期入金及び普通出金のトランザクションＴ１は既にコミットしている可能性が高い。すなわち、派生起動トランザクションＴ１はその付随業務である取消再カットメインである派生トランザクションＴ２のコミットを待機せずにコミットする。トランザクションＴ１がコミットしていると、リージョン０は空いているため、電気料引落の取消を行う派生トランザクションＴ３は、リージョン０にスケジュールされることがある。
【０１５６】
図１５乃至図１７は、この状態での派生起動情報の格納及び派生メッセージの出力や、ＦＩＦＯの推移を説明するための説明図である。この例では、ＩＢＭ社のＭＶＳで動作するＩＭＳをＦＰで高速化し、さらにＳＡＩＬによるＦＩＦＯ及び編集定義を使用し、そして、業務メインによりオペコードテーブルを用いて各トランザクションを管理する。この例では、第２実施形態で説明している派生インデックスＤＢ及び派生管理ＤＢを用いている。
【０１５７】
業務メインは、ＡＴＭから定期入金の業務処理要求を、図１５の符号Ｍ１で示す入力メッセージの形式で受信する。入力メッセージＭ１中、Ｈはヘッダー、オペコードは定期入金を示す０４００１（図１３参照）、金額は５０，０００であり、ここでは、普通預金の店番２１１の口座２１ｙｙｙｙから出金して、２１０店番の口座３０００ｘｘｘｘｘに入金する処理を要求する。ＩＭＳは、入力メッセージＭ１を待ち行列から取り出すと、空いているリージョン０へスケジュールし、トランザクションを開始させる。ＳＡＩＬ及び業務メインは、図１７に示すように、このリージョン０内に、入力メッセージＭ１から所定の入力編集定義を用いて定期入金のＦＩＦＯ８６Ａを展開する。図１５に示すように、ＦＩＦＯ８６Ａには、予め定められた位置に、オペコードや、定期入金する店番や、入金金額等が格納される。そして、業務メインは、定期入金のオペコードテーブルを参照して所定のプログラムを呼び出し、実行させる。定期入金プログラムは、普通預金からの出金を依頼するために、オペコード０１００１への連動を起動する。このとき、連動編集定義に基づいて、普通出金用のＦＩＦＯ８６Ｂがセットされる。結果コードは、普通預金からの出金に成功するか否かを示すコードである。
【０１５８】
普通預金出金は、ＦＩＦＯにセットされた２００１／３／６を勘定日とする残高を参照し、出金が可能であるか否かを判定し、出金が可能であれば、６日の残高を１０，０００に更新する。そして、先日付の勘定日が存在するため、７日の残高も更新する。７日の残高がマイナスとなったため、取消再カットメインを処理する開始日（派生日付）を２００１／３／７にセットして、派生起動要求依頼を業務メインに渡す。例えば、派生起動のマクロを実行する。ＳＡＩＬは、普通出金ＦＩＦＯの内容から派生編集定義を用いて派生メッセージ（取消再カットメイン）Ｍ２を生成する。このとき、業務メインは、図１１に示す処理を呼び出す。図１１に示すように、呼び出された派生要求共通処理は、普通出金ＦＩＦＯの内容を派生管理ＤＢに格納する。この例では、ＪＯＢ番号が「０００」であるため、図１７に示すようにインデックス領域１のインデックス・ビットマップを読み取り先頭が「０」であったことから、派生管理通番を１とする。そして、このエントリー日付や時刻等と共に、図１５に示す普通出金ＦＩＦＯ８６Ｂの内容を派生管理ＤＢ７０の派生管理通番１のセグメントに記録する。普通出金ＦＩＦＯが記録された状態では、図１７に示すように、インデックス・ビットマップの先頭の派生インデックスビットがＯＮ（１）であり、また、派生管理通番１の使用中フラグが使用中（１）となる。
【０１５９】
図１５に示すように、普通預金の出金に成功すると、連動戻り編集定義を用いて、連動戻りブロックに出金に成功した旨を示す結果コード（００００）を記録する。定期入金処理は、定期入金に成功したため、定期入金ＦＩＦＯから出力編集定義を用いて出力メッセージを生成し、ＡＴＭに送信させる。これにより、ＪＯＢＦＰ０００のトランザクションＴ１はコミットする。
【０１６０】
ＩＭＳは、派生メッセージＭ２をリージョン１にスケジュールし、ＳＡＩＬは、派生メッセージから取消再カットＦＩＦＯ８６Ｄをセットする。取消再カットメインは、派生トランザクションであるため、業務メインは、まず図１２に示す処理を行う。すなわち、派生特性管理共通処理として、派生管理通番をキー値とした派生管理ＤＢの読み込みを行う。ここでは、派生管理通番１のセグメントを読み取る。すなわち、派生管理ＤＢ７０に格納された普通出金ＦＩＦＯ８６Ｂを読み出す。これにより、トランザクションＴ１のコミットを待機すると共に、Ｔ１のアボートの有無の確認を行う。普通出金を含むトランザクションＴ１が正常にコミットした後、ステップＳ７５に示すように、適用業務プログラムを呼び出す。ここでは、派生メッセージのオペコードである０５００１（取消再カットメイン）を構成するプログラムを呼び出す。取消再カットメインは、取消の対象を特定し、その自振通番（１２３４５６）や、取消金額等を取消再カットＦＩＦＯ８６Ｄにセットし、派生起動要求依頼を行う。業務メインは、図１１に示す派生要求共通処理を実行させる。このとき、取消再カットメインはＪＯＢ番号００１で動作しているため、図１７に示すように、派生管理通番は４０１となる。このため、ＦＩＦＯ８６Ｄの派生管理通番の項目を１から４０１へと更新し、このＦＩＦＯ８６Ｄを派生管理通番４０１のセグメントに格納する。そして、派生編集定義に従って、図１６に示す派生メッセージＭ３を生成する。
【０１６１】
派生メッセージＭ３は自振（電気料引落）の取消であり、オペコードは０２５０１である。トランザクションＴ３は連動取引を用いてこの自振取消を行い、連動受動業務である普通出金取消処理は派生メッセージＭ４を出力させる。このとき、トランザクションＴ３がリージョン０にスケジュールされたとする。
【０１６２】
図１７に示す例では、トランザクションＴ２の派生要求共通処理が派生メッセージを出力させた時点では、トランザクションＴ１がコミットしている。これは、派生起動トランザクションＴ１は派生トランザクションＴ２のコミットを待機せずに早期にコミットすることで、ここでは定期入金処理の応答性を確保していることによる。一方、派生メッセージ（自振取消）Ｍ３は、トランザクションＴ２がコミットする前にスケジュールされる。このため、自振取消を主業務とするトランザクションＴ３はリージョン０にスケジュールされた。トランザクションＴ３では、まず、取消再カットメインであるトランザクションＴ２のコミットを待機するために、派生管理通番４０１の派生管理情報を読み出そうとする。
【０１６３】
トランザクションＴ２がコミットすると、図１２に示すように、業務メインは、派生特性管理共通処理（Ｓ７６，Ｓ７７）をトランザクションＴ２の一部として実行する。さらに、Ｓ７８及びＳ７９もトランザクションＴ２の一部として実行する例では、インデックス領域１の先頭の派生インデックスビットがＯＦＦに更新された後に、派生トランザクションＴ２がコミットする。この場合、トランザクションＴ３が派生トランザクションを起動する時には、すでに派生管理通番１が空いている。
【０１６４】
図１７に示す例では、派生インデックスＤＢのＯＦＦ（対応する派生管理通番が使用可）への更新を別トランザクションとして起動する。この場合、ステップＳ７７が終了した段階でトランザクションＴ２はコミットする。このとき、トランザクションＴ３は派生管理通番４０１の読み出しに成功し、さらに普通預金出金取消が完了すると、再度取消再カットメインを起動しようとする。このとき、トランザクションＴ２によって起動された派生インデックスビットのＯＦＦへの更新処理（派生ＤＢ制御処理）が完了していないと、インデックス領域１の先頭の派生インデックスビットは１のままである。このため、次に空いているビット位置が２の派生インデックスビットを特定する。トランザクションＴ３からの派生起動情報は、普通出金取消ＦＩＦＯ等であり、これが派生管理通番２のセグメントに格納される。
【０１６５】
トランザクションＴ２によって起動された派生ＤＢ制御処理が当該インデックスビットを更新すると、インデックス領域１のインデックスビットの先頭ビットは０となる。このため、次にリージョン０で実行されるトランザクションが派生トランザクションを起動する場合には、派生管理通番１が利用される。このように派生管理通番を繰り返し利用するため、本実施形態では、派生管理ＤＢ及び派生インデックスＤＢの再編成処理が不要である。
【０１６６】
図１５乃至図１７に示す例では、各リージョンは、一般トランザクションと派生トランザクションの双方を実行するものとして説明したが、図１８に示すように、ＪＯＢ番号（リージョン）を一般トランザクションと派生トランザクションとに別々に割り当てるようにしても良い。図１８に示す例では、全てのＪＯＢが派生トランザクションによって使用されるという可能性がなくなるため、オンラインの応答性の悪化を防止することができる。そして、業務処理要求（メッセージ）の取り扱いを容易にするために、図１８に示す例では、オンラインシステムが、待ち行列１３として、オンライントランザクションやセンター一括処理の実行を要求するメッセージ（電文）を一時的に記憶する一般待ち行列１３Ａと、派生トランザクションの実行を要求する派生メッセージを一時的に記憶する派生待ち行列とを備えている。２種類の待ち行列を併用することで、トランザクションの総量制御が容易となる。
【０１６７】
＜総量制御＞
再度図７を参照すると、オンラインシステム（または、トランザクション制御システム）は、図１８に示す一般待ち行列１３Ａ及び派生待ち行列１３Ｂで滞留しているトランザクション数を監視する滞留監視部７８と、この滞留監視部７８によって監視される各待ち行列でのトランザクションの滞留数に応じて前記派生起動トランザクション又は前記派生トランザクションの起動を制御する総量制御部７９とを備えている。
【０１６８】
図１９は、滞留監視処理の一例を示すフローチャートである。滞留監視部７８は、前記一般待ち行列又は派生待ち行列の滞留数が予め定められた第１レベル以上である場合には（ステップＳ８１，Ｓ８３）、派生起動取引中断ビットをＯＮとする（ステップＳ８２，Ｓ８４）。図１９に示す例では、それぞれの待ち行列１３Ａ，１３Ｂに格納されたメッセージ数が２００を越えた場合に、派生起動取引中断ビットをＯＮとしている。そして、前記派生待ち行列に滞留しているトランザクション数が前記第１レベル（２００）よりも多い数にて予め設定された第２レベル（５００）以上である場合には（ステップＳ８５）、派生中止ビットをＯＮとする（ステップＳ８６）。一方、上記各ビットがＯＮとなった後に、それぞれの待ち行列の滞留数が０となった場合には（ステップＳ８７）、各ビットをＯＦＦとする（ステップＳ８８）。この滞留監視部７８による監視処理は、所定の監視時間間隔で、例えば３０秒ごとに繰り返し実行する。滞留監視部７８は、派生起動取引中断ビットや、派生中止ビットを図７に示すシステム状況ＤＢ８３に格納する。
【０１６９】
図２０は、派生トランザクションの実行を待機させる処理の一例を示す図表である。総量制御部７９は、前記派生起動取引中断ビットがＯＮである場合には前記派生トランザクションを起動する業務処理要求の入力を中断させる派生起動取引入力中断制御機能２８を備える。派生トランザクションを起動する業務処理要求としては、例えばセンター一括処理がある。派生起動取引入力中断制御機能２８は、本実施形態では、例えば、センター一括処理を要求するセンターカット電文を入力するとき（例えば、ＳＡＩＬのＥＸＩＴ処理時）、システム状況ＤＢ８３に格納された派生起動取引中断ビットを参照し、派生起動取引中断ビットがＯＮであると、センターカット電文の入力を中断する。従って、センター一括処理自体を待機させることでシステム負荷を軽減し、且つ、センター一括処理は取消再カットメインを派生トランザクションとして起動する可能性があるため、派生トランザクションの起動を抑制することができる。
【０１７０】
また、総量制御部７９は、システム状況ＤＢ８３に格納された派生中止ビットがＯＮである場合に、派生起動要求があった時には、当該派生起動情報を前記派生管理ＤＢに登録後、派生トランザクションの起動を行わない派生起動中止制御機能３０を備える。図１８に示す例では、派生起動トランザクションを管理する派生起動要求共通処理は、派生起動情報を登録後、派生中止ビットがＯＮである場合には、派生メッセージを出力しない。すると、派生起動トランザクションがコミットし、派生トランザクションがアボートされたのと同様の状態となる。すなわち、派生起動中止制御機能３０は、派生メッセージの出力処理時にシステム状況ＤＢ８３の派生中止ビットを参照し、派生中止ビットがＯＮである場合には付随処理である派生トランザクションを起動しない。
【０１７１】
また、総量制御部７９は、前記派生中止ビットがＯＮである場合に業務処理要求を受信した場合であって、当該業務処理要求に滞留時停止指定がある場合には、当該業務処理要求の処理を不能としてエラー出力する滞留時エラー制御機能３１を備えるようにしても良い。図１３を参照すると、動作環境指定として、オペコードに続いて滞留＝Ｎｏ，センター一括＝Ｙｅｓ等の指定がある。この動作環境指定で滞留＝Ｙｅｓとなっているオペコードの処理を要求されたときに、派生中止ビットがＯＮとなっている場合には、滞留時エラー制御機能３１を備える例では、当該メッセージを処理不能としてエラーを出力する。
【０１７２】
＜派生再起動＞
次に、派生トランザクションの再起動について説明する。派生トランザクションは、アボートされた場合や、派生トランザクション実行中にシステム障害が発生した場合や、派生トランザクションの起動が中止された場合に、事後的に再起動を行う。派生トランザクションの再起動の手順を明確にすることで、派生起動トランザクションと派生トランザクションとを利用した派生利用トランザクションの実際上の原子性を保つことができる。
【０１７３】
再度図７を参照すると、演算手段４は、前記派生インデックスＤＢ６８及び派生管理ＤＢ７０を参照して派生インデックスビット及び使用中フラグがＯＮで且つ派生管理ＤＢに派生起動情報を格納した後予め定められた時間以上経過している派生管理通番を派生再起動要と判定する派生再起動要否監視部７６と、派生再起動要否監視部７６によって再起動要と判定された派生管理通番を再起動する場合には、当該派生管理通番によって特定される派生起動情報に基づいて派生トランザクションを起動すると共に当該派生管理通番へ派生起動情報を格納した時刻を更新する派生再起動制御部７７とを備えている。
【０１７４】
まず、アボートの態様を説明する。派生起動トランザクションがアボートした場合、派生起動情報が一旦格納されていたとしてもロールバックによりその更新が無効となるため、派生管理通番の使用中フラグがオフとなる。このため、派生トランザクションは起動しない（図１２，Ｓ７４）。従って、派生起動トランザクションのアボートでは派生トランザクションの再起動が必要となることはない。
【０１７５】
派生トランザクションがアボートした場合、使用中フラグを使用可に更新していたとしても、この使用可への更新はロールバックにより取り消される。従って、派生トランザクションの原子性により、派生トランザクションがアボートした場合には使用中フラグが使用中となっていることが保証される。従って、派生再起動要否監視部７６は、派生インデックスビット及び使用中フラグがＯＮで且つ派生管理ＤＢに派生起動情報を格納した後予め定められた時間以上経過している派生管理通番を派生再起動要と判定することができる。デッドロックの発見に処理開始後の経過時間による判定が極めて有効であるのと同様に、本実施形態では、派生トランザクションのアボートの判定に派生起動情報のエントリー後の経過時間を用いることで、確実に派生トランザクションのアボートを検索する。
【０１７６】
また、派生トランザクションの終了処理にて、派生インデックスビットを派生ＤＢ制御処理にて実行する場合、この派生ＤＢ制御処理がアボートしたときには、派生トランザクションによる使用中フラグの更新は成功し、すでにコミットしているため、使用中フラグがオフで、派生インデックスビットがＯＮとなる。この場合、派生トランザクションの付随業務の内容は正常にコミットしているため、派生トランザクションを再起動する必要はない。
【０１７７】
派生再起動制御部７７は、派生再起動要否監視部７６によって再起動要と判定された派生管理通番を再起動する場合には、当該派生管理通番によって特定される派生起動情報に基づいて派生トランザクションを起動すると共に当該派生管理通番での派生起動情報を格納した時刻を更新する。本実施形態では、自動的な再起動を行うのではなく、アボートした派生トランザクションの存在をオペレータに表示し、オペレータからの再起動の要求を待って再起動処理を行う。このとき、派生再起動制御部７７は、派生トランザクションの再起動時にエントリー時刻を更新する。
【０１７８】
図２１は、派生トランザクションの再実行を派生管理業務により行う構成を示すブロック図である。コンソール端末２Ａから派生再実行要求９０を受信すると、そのコマンドを解析し、特定の派生トランザクションを再起動するか、又は、アボートした全派生トランザクションを一括して再起動するかの判定を行う。派生管理通番で指定された一件の派生トランザクションを再起動する場合、派生管理業務９２は、派生管理通番から派生管理ＤＢに格納されているＦＩＦＯを特定し、このＦＩＦＯを派生管理業務９２のＦＩＦＯへセットする。そして、この派生管理業務のＦＩＦＯに基づいて派生トランザクションの起動処理を行う。派生受動業務９３として、派生トランザクションが再起動される。
【０１７９】
全トランザクションを再起動する場合、派生管理業務９２は、予め定められた数の派生トランザクションを起動すると、図２（Ｃ）に示すような形式で、派生管理業務９５を派生起動する。派生管理業務９５も、予め定められた数の派生トランザクションを起動すると、派生管理業務を派生トランザクションとして起動する。各派生管理業務が予め定められた数の再起動しか行わないのは、１つのＪＯＢ番号から起動できる派生トランザクションの数が派生管理通番の数である図８乃至図１０に示すＭ（例えば、４００＋予備）以下に制限されるためである。
【０１８０】
図２２は、派生再起動要否監視部７６による派生再起動要否判定処理の詳細構成を示すフローチャートである。この派生再起動要否判定処理は、アボートされ、且つ再起動が必要な派生トランザクションの有無を監視する処理である。この派生再起動要否判定処理は、コンソール端末２Ａからのコマンド入力により実行する。また、一定時間間隔で自動的に起動するようにしても良い。コマンド入力により実行する場合、日付変更を行う前や、また、ある処理の終了時刻の前などに実行する。また、トランザクションがアボートされるとコンソール端末２Ａにその旨が表示されるため、この表示があったときに実行するようにしても良い。
勘定系システムを例とすると、例えば他の金融機関への振込処理はある時間までに完了させなければならないため、この為替の中断を指示する為替中断コマンドの入力前に、この派生再起動要否判定処理を実行することでアボートされた派生トランザクションの有無の確認を行う。例えば、上述した承認通知処理は派生トランザクションを利用するが、この派生トランザクションがアボートされていないことを確認する。また、日付変更時には再起動が必要な派生トランザクション（付随処理）が一件もないことが必要であるため、この日付変更コマンドの入力前に派生再起動要否判定処理をコマンド入力により起動する。
図２２を参照すると、派生再起動要否監視部７６は、まず、対象インデックス領域番号を０にセットする（ステップＳ９１）。続いて、派生インデックスＤＢ７８のインデックス・ビットマップを「読み取りのみ」のモードで読み込む（ステップＳ９２）。これは、通常の派生起動トランザクションとのインデックス・ビットマップに関するコンテンションの発生を防止するためである。続いて、インデックスビットの位置を先頭（１番目）にセットする（ステップＳ９３）。そして、セットされた位置のビットを読み取り、この派生インデックスビットがＯＮ（使用中）であるか否かを判定する（ステップＳ９４）。派生インデックスビットがＯＮであれば、派生管理ＤＢの内容を読み取る（ステップＳ９５）。そして、派生起動情報のエントリー時刻を参照し、派生取引起動時刻から３０秒以上経過しているか否かを判定する（ステップＳ９６）。３０秒以上経過している場合には、再派生不要ビットがＯＮか、又は派生管理ＤＢの使用中フラグが使用可（０）であるか否かを確認する（ステップＳ９７Ａ）。
再派生不要ビットは、例えば端末折り返し連続処理などでＯＮとされている。派生インデックスビットが使用中で、派生管理ＤＢの使用中フラグがＯＦＦであるのは、派生トランザクションがコミットし、派生ＤＢ制御処理がアボートした場合であるため、派生トランザクションの再起動は不要である。ステップＳ９７Ａでノーであれば、その派生管理通番で起動された派生トランザクションについて再派生が必要と判定し、コンソール端末２Ａに、派生管理通番や、起動業務の識別コードや、派生受動業務のオペコードや、派生起動情報のエントリー日付及び時刻や、当初の業務処理要求の入力店番や端末番号や、さらに、派生取引対象口座の店番や口座番号等を出力する（ステップＳ９７Ｂ）。この再派生関連情報を参照して、オペレータは、当該派生管理通番で管理される派生トランザクションを再起動するか否か判定する。
【０１８１】
派生インデックスビットがＯＦＦである場合や（ステップＳ９４，ノー）、ＯＮであったとしても派生取引起動時刻から３０秒以上経過していない場合には（ステップＳ９６，ノー）ステップＳ９８Ａ，Ｓ９８Ｂを経由して次のインデックスビット（次の派生管理通番）の判定を行う。そして、派生取引起動時刻から３０秒以上経過していても、再派生不要ビットがＯＮであったり、また、派生トランザクションがコミットしたものの派生ＤＢ制御処理がアボートした場合（派生管理ＤＢ７０の使用中フラグが使用可）であるときも（ステップＳ９７Ａ，イエス）、次のインデックスビットの判定を行う。
ステップＳ９８Ａでは、インデックスビット位置が最終であるか否かを確認する。最終位置でなければ、ビット位置を１つずらして対応する次の派生管理通番を処理対象にセットし（ステップＳ９８Ｂ）、ステップＳ９４に処理を移す。一方、インデックスビットの位置が最終であれば、次のリージョンに対応するインデックス領域番号を判定対象とするため、対象インデックス領域番号に１を加算してセットし、ステップＳ９２に処理を移す。一方、ステップＳ９９Ａにて、すべてのインデックス領域（リージョン）の探索が完了している場合には、この派生再起動要否判定処理を終了する。
【０１８２】
図２３は、アボート又は起動中止された全ての派生トランザクションを一度のコマンドで順に再起動する処理例を示すフローチャートである。図２３に示す例では、派生再起動制御部７７は、まず、初回起動時に対象インデックス領域番号として０をセットする（ステップＳ１０１）。続いて、対象インデックス領域番号のインデックス・ビットマップのうち、使用中のビット位置を探索する（ステップＳ１０２）。使用中のビットがある場合には、その対象インデックス領域番号とビット位置とから派生管理通番を算出し、派生管理ＤＢに格納された内容を読み込む（ステップＳ１０３）。そして、使用中フラグがＯＮ（使用中）で、且つ派生トランザクションの起動時刻（派生起動情報のエントリー時刻）から５分以上経過しているか否かを判定する（ステップＳ１０４）。５分以上の経過がなければ、次に使用中である派生インデックスビットを探索する（ステップＳ１０２）。
【０１８３】
派生管理ＤＢの使用中フラグが「使用中」で、且つ派生起動情報のエントリーから５分以上経過している場合には、派生管理ＤＢ７０に格納されている派生起動情報に基づいて派生トランザクションの起動を制御する（ステップＳ１０５）。具体的には、派生管理ＤＢ７０に格納されたＦＩＦＯをセットし、派生管理ＤＢ７０に格納された派生編集番号に応じて当該ＦＩＦＯから派生メッセージを生成する。派生起動制御を行うと、再派生処理回数をインクリメントする（ステップＳ１０６）。そして、派生取引起動時刻を現時刻に変更して派生管理ＤＢを更新する。続いて、次の使用中のインデックスビットを探索する（ステップＳ１０２）。対象インデックス領域番号のインデックス・ビットマップを全て確認した場合には（ステップＳ１０２）、次の派生インデックスビットについて検討するため、対象インデックス領域番号に１を加算してセットする（ステップＳ１０８）。このとき、再派生処理回数（起動した派生トランザクションの数）が一定数（例えば、８０）を越えている場合には、再派生処理回数を０にクリアして、派生再起動処理を派生トランザクションとして起動する（ステップＳ１１１）。再起動された派生再起動処理では、初回起動時ではないためステップＳ１０１をパスし、セットされたインデックス領域番号のインデックス・ビットマップの派生トランザクションの再起動を検討する。
【０１８４】
ステップＳ１０８にて、再派生処理回数が一定数を越えていない場合には、全てのインデックス領域番号（インデックス・ビットマップ）の探索が完了したか否かを確認し（ステップＳ１１０）、未検討のインデックス・ビットマップが残っている場合には、対象インデックス領域番号に１を加算して、ステップＳ１０２に処理を移す。これにより、全てのインデックス・ビットマップについてアボートされた派生トランザクションの有無を探索することができる。
【０１８５】
上述したように第２実施形態によると、派生インデックスＤＢをＪＯＢ番号毎にアクセス可能とし、さらに、派生起動情報を派生管理ＤＢに格納するため、並列に処理されているトランザクション間のコンテンション防止し、デッドロックの発生を防止し、さらに派生管理ＤＢの再編成不要としつつ、一般的なＤＢのロック機構を用いて派生トランザクションの特性を管理することができる。
【０１８６】
【第３実施形態】
図１２に示す派生特性管理共通処理にて、ステップＳ７９を派生トランザクション内の処理とすると、デッドロックが発生する可能性がある。このデッドロックは、プログラムの構築の仕方によって回避することができるが、その回避のために適用業務プログラムのプログラマが留意すべき事項は、複雑である。このため、第３実施形態では、第２実施形態を拡張するものとして、派生ＤＢを用いつつもデッドロックの発生を回避することができる仕組みを開示する。具体的には、ステップＳ７９を派生トランザクションとは別のトランザクション（派生ＤＢ制御処理）として実行するものである。
【０１８７】
図２４は、本実施形態の構成を示すブロック図である。図２４に示すオンラインシステムは、ＡＴＭ等の端末１Ａ及び営業店端末１Ｂからネットワークを介して入力される業務処理要求を受信すると共に、コンソール端末２Ａから入力される業務処理要求（コマンド）を受信する受信手段２と、この受信手段２にて受信した業務処理要求をオンライントランザクションとして処理する演算手段４と、この演算手段４による業務処理要求の結果を記録するファイル６とを備えている。
【０１８８】
そして、ファイル６は、前記オンライントランザクション又は所定の派生トランザクションである派生起動トランザクションの実行の一部として起動される派生トランザクションの派生起動情報を派生管理通番毎に記録すると共に当該派生管理通番が使用中であるか否かを示す使用中フラグを有する派生管理ＤＢ７０と、この派生管理ＤＢ６８での派生管理通番を前記トランザクションのＪＯＢ番号を単位とした複数の派生管理通番から使用可の派生管理通番を特定すると共に前記派生管理通番が使用中であるか否かを示す派生インデックスビットを前記ＪＯＢ番号毎に複数有する派生インデックスＤＢ６８とを備えている。この派生インデックスＤＢ及び派生管理ＤＢ７０の構成及び役割については、上記第２実施形態と同様である。従って、好ましい例ではＪＯＢ番号からインデックス・ビットマップを特定し、このインデックス・ビットマップを参照して使用可の派生管理通番（派生インデックスビットのビット位置）を特定する。
【０１８９】
図２４に示す例では、演算手段４が、前記オンライントランザクション又は派生トランザクションの種類を特定するオペコードに応じて当該トランザクションを構成するプログラムの実行を管理する業務メイン処理部１００と、この業務メイン処理部１００によって呼び出されたプログラムを実行する業務処理部１１０とを備えている。ここでは、演算手段４の構成を、実際のプログラムの配分に従って、各プログラムをトランザクションとして管理する業務メイン処理部１００と、実際にプログラムを実行する業務処理部１１０とに機能分けをする。
【０１９０】
演算手段４では、ＩＭＳ上でＦＰ及びＳＡＩＬが各種のサービスを提供しているとする。図２４に示すメッセージ入力手段８（例えば、ＳＡＩＬの入力インタフェース）は、業務処理要求（入力メッセージ）を受信すると、入力メッセージ上の業務識別コード、媒体タイプ、入力編集番号をもとに入力編集定義テーブルを特定する。本実施形態では、業務識別コードと入力編集番号とはオペコードから変換する。入力インタフェースは、入力編集定義テーブルに従って、メッセージ上のデータを指定された編集を行い、編集後のデータを指定されたＦＩＦＯのフィールドへセットする。この編集の完了後、ＳＡＩＬは業務識別コードに対応した適用業務プログラムを呼び出す。本実施形態では、全業務に共通の業務メインと呼ばれるプログラムを呼び出す。
【０１９１】
業務メイン処理部１００は、図２５に示すように、業務メインの（１）開始処理を実行する。そして、例えば図１３に示すようなオペコードテーブルに基づいて適用業務プログラムを特定し、呼び出す。図２５に示す例では、業務メインは、派生起動トランザクションの一部となる派生起動ＡＰＰＬを呼び出す。すると、業務処理部１１０は、この派生起動ＡＰＰＬを実行する。この実行中に、業務処理部１１０は、派生起動要求依頼（マクロを用いる場合には、派生要求マクロ）を業務メインに入力する。
【０１９２】
業務メインは、派生起動要求依頼を受信した場合には、派生要求共通処理を呼び出す。すなわち、業務メイン処理部１００は、派生起動トランザクションの実行によって派生起動要求依頼を受信した場合には派生要求共通処理を当該派生起動トランザクションの一部として実行する派生要求共通処理呼び出し機能１０２を備えている。派生要求共通処理は、例えば図１１に示す処理である。業務処理部１１０は、この派生要求共通処理を実行する派生要求共通処理機能１１２を備える。派生要求共通処理機能１１２は、例えば、ＣＰＵが、図２５に示す派生要求共通処理指令１１２Ａを実行することで実現する。
【０１９３】
派生要求共通処理機能１１２は、図２５に示すように、派生要求共通処理が呼び出されて処理を開始すると（１）、当該派生起動ＡＰＰＬ１１１Ａがスケジュールされているリージョンでの当該トランザクションのＪＯＢ番号を特定し（２）、前記派生インデックスＤＢを参照する（３）。この参照により、前記派生管理ＤＢの派生管理通番を特定して派生インデックスビットをＯＮ（使用中）にする（４）。そして、ビット位置から派生管理通番を算出し、これを当該リージョン内のＦＩＦＯにセットする（６）。そして、派生インデックスＤＢ６８の残り個数及び派生件数を更新する（７）。さらに、派生管理通番のセグメントに派生起動情報を格納し、使用中フラグを使用中に更新する（８）。そして、派生要求共通処理は、システム状況ＤＢ８３に格納された派生中止ビットを参照し、派生中止ビットがＯＦＦであればＳＡＩＬ（ＯＳの一部）に派生起動要求（派生要求マクロ）を入力する（９）。その後、業務メインに戻る（１０）。派生中止ビットがＯＮであれば、派生要求マクロを入力せず、派生起動トランザクションをコミットさせる。
【０１９４】
派生要求マクロが出力されると、ＳＡＩＬの連動インタフェースは、起動業務識別コード・プログラムで指定した受動業務識別コード・編集番号から、派生編集定義テーブルを特定する。本実施形態では、受動業務識別コードと派生編集番号は派生受動処理（派生トランザクション）のオペコードから変換する。連動インタフェースは、派生編集定義テーブルに従って、指定された派生起動業務側ＦＩＦＯ上のデータを、指定された編集を行って派生メッセージへセットする。連動インタフェースは、派生メッセージを受信すると、入力メッセージ上の起動業務識別コード・受動業務識別コード・派生編集番号をもとに派生編集定義テーブルを特定する。連動インタフェースは、派生編集定義テーブルに従って、派生メッセージ上のデータを、指定された編集を行った後指定されたＦＩＦＯのフィールドへセットする。この編集完了後、ＳＡＩＬは業務メインを呼び出す。これにより、派生トランザクションの処理が開始される。呼び出された業務メインは、図２５に示す例では、派生特性管理共通処理指令１０４Ａを実行する。
【０１９５】
図２５に示す本実施形態では、「派生特性管理共通処理１０４Ａ」は、例えば図１２に示す処理のうち、派生インデックスビットを使用可に更新する処理を除いた部分である。図２４及び図２５に示す例では、業務メイン処理部１００が派生特性管理共通処理１０４Ａを実行する派生特性管理共通処理機能１０４を備える。
【０１９６】
派生特性管理共通処理機能１０４は、図２５に示すように、派生特性管理共通処理１０４Ａを開始すると（１）、まず、派生管理通番をキー値として派生管理ＤＢの読み込みを試みることで（２）、派生起動トランザクションとの直列性を保つ。派生管理情報の読み込みに成功すると、使用中フラグをチェックする。使用中フラグがＯＦＦであれば、派生起動トランザクションがアボートされたとして、派生受動ＡＰＰＬを呼び出さずに業務メインを終了する（４）。一方、この派生管理通番の使用中フラグが使用中である場合には、当該派生トランザクションのオペコードに応じた派生受動業務プログラムを呼び出して実行させる（４）。
【０１９７】
業務処理部１１０は、派生受動ＡＰＰＬを実行し、終了すると、業務メインに処理を戻す。派生特性管理共通処理は、派生受動ＡＰＰＬが終了した後に、前記派生管理ＤＢの使用中フラグをオフに更新して（６）、さらに所定の派生ＤＢ制御処理を派生トランザクションとして起動させる（７）。ＳＡＩＬは、派生トランザクションのＦＩＦＯを参照して所定の編集定義に基づいて派生メッセージを出力する。派生メッセージがスケジュールされると、派生ＤＢ制御処理が実行される。
【０１９８】
前記業務処理部１１０は、派生インデックスビットを使用可へと更新する派生ＤＢ制御処理を派生トランザクションとはさらに別のトランザクションとして実行する派生ＤＢ制御処理機能１１４を備えている。派生ＤＢ制御処理機能１１４は、ＣＰＵが派生ＤＢ制御処理指令１１４Ａを実行することで実現する。派生ＤＢ制御処理１１４Ａでは、まず、派生管理通番から派生インデックスＤＢ６８のインデックス領域番号とビット位置とを算出する（２）。そして、算出したインデックス領域番号をキー値として派生インデックスＤＢ６８のインデックス・ビットマップを読み込む（３）。続いて、派生管理通番をキー値として派生管理ＤＢ７０を読み込む（４）。この派生管理ＤＢの読み込みにより、派生特性管理共通処理１１２Ａとの直列性が維持される。そして、派生管理ＤＢの使用中フラグがＯＦＦであるか否かを確認し、ＯＦＦの場合に派生インデックスビットをＯＦＦ（使用可）にして派生インデックスＤＢを更新する。
【０１９９】
図２６は、派生トランザクションの一部として、派生トランザクションの完了時に派生インデックスＤＢの派生インデックスビットをＯＦＦとした場合に、生じる可能性があるデッドロックの一例を示す説明図である。すなわち、派生インデックスＤＢ６８を用いて派生管理通番を特定する派生ＤＢ制御処理を派生トランザクションと別のトランザクションとしない場合に生じる可能性のあるデッドロックの態様の一例を示す図である。
【０２００】
デッドロックは、２つのトランザクションが相互に相手方の処理の完了を待機する場合に生じる。例えば、トランザクションＴ１がＤＢｘを読み込み、これをロックした後、次に派生インデックスＤＢ６８を読み込もうとする。一方、トランザクションＴ２が派生インデックスＤＢ６８を読み込み、これをロックした後、次にＤＢｘを読み込もうとしたとする。トランザクションＴ１が派生インデックスＤＢ６８を読み込もうとしたときに、この派生インデックスＤＢ６８がトランザクションＴ２によってロックされている場合に、トランザクションＴ１とＴ２はデッドロックとなる。
【０２０１】
図２６に示す例では、まず、ＪＯＢＦＰ０００から派生起動要求が出力され、この派生トランザクションＴ２はＪＯＢＦＰ００１にスケジュールされた。トランザクションＴ２では、別のオペコードに連動するが、連動先ではあるＤＢｘをキーｙで読み込む。トランザクションＴ２は連動処理が完了してから、派生トランザクションの後処理（派生特性管理共通処理）として、派生管理ＤＢの使用中フラグをＯＦＦとし、派生インデックスＤＢの派生インデックスビットをＯＦＦとする。このとき、派生インデックスＤＢのキー値は、インデックス領域番号であるから、トランザクション１のＪＯＢ番号である０がキー値となる。派生管理ＤＢのキー値（派生管理通番）は、ここでは１とする。
【０２０２】
トランザクションＴ２の処理中に、トランザクションＴ３がＪＯＢＦＰ０００でスケジュールされた。トランザクションＴ３では、別オペコードに連動するが、連動先では派生トランザクションを起動するため、派生インデックスＤＢをキー値を０として読み、派生管理ＤＢの派生管理通番１のセグメントに派生起動情報を格納する。トランザクションＴ３では、連動処理が完了してから、ＤＢｘを読み込む。
【０２０３】
さて、トランザクションＴ２では、ＤＢｘを読み取った後、派生インデックスＤＢをキー値０として読み取ろうとする。トランザクション３では、派生インデックスＤＢを読み取った後、ＤＢｘを読みに行く。このため、トランザクションＴ２にて連動受動処理がＤＢｘを読み込んでロックした後、派生インデックスＤＢを読み取る前のタイミングで、トランザクションＴ３が派生インデックスＤＢを読み取ると、デッドロックとなる。また、トランザクションＴ３が派生インデックスＤＢを読み取った後、連動処理が完了してＤＢｘを読み取る前のタイミングで、トランザクションＴ２がＤＢｘを読み取ると、デッドロックが生じる。
【０２０４】
デッドロックの発生を完全に防止する手法は、並列処理を行わないことであるが、これは採用できない。ロックに関しては、並列処理の直列化を維持するために、あるトランザクションは、ロックを取得するフェーズと、ロックを解放するフェーズとの２相ロッキングプロトコルに従う必要がある。従って、一度ロックを解放すると、そのトランザクションはロックを取得してはならない。この２相ロッキングプロトコルの要件によると、デッドロックが生じた場合には一方のトランザクションをアボートしなければならない。
【０２０５】
デッドロックを回避しつつ、並列性も維持する方法は、トランザクションのロックの順序を調整することである。例えば、全てのトランザクションが同一の順序でロックを要求すれば、デッドロックを回避することができる。しかし、これはプログラマにとって厳しい制限となる。また、トランザクションが使用する全てのロックをその開始時に取得してから、実際の処理を行うことによっても、デッドロックの発生を回避することができるが、この場合、限りなく直列処理に近くなり、並列処理の利点が減少する。
【０２０６】
これらの標準的な手法でデッドロックを回避するためには、「派生トランザクションを起動する可能性がある連動受動処理に連動する前に、連動後に読むＤＢを連動前に読んでおく」必要がある。これにより、実行順序が同一となる。全ての連動起動処理がこの条件を満たすのであれば、図２６に示すデッドロックの発生を回避することができる。しかしながら、連動起動業務の開発者が、このＤＢの読み込み順序を守るよう意識するのは、負担が大きく、困難である。
【０２０７】
このため、第３実施形態では、派生ＤＢ制御処理として、派生インデックスＤＢの派生インデックスビットをＯＦＦにする処理を別トランザクションとしている。このため、派生特性管理共通処理では、派生インデックスＤＢの派生インデックスビットの更新を行わない。従って、１つのトランザクション内でＤＢｘのロックと派生インデックスＤＢのロックとを行うことがなくなる。派生ＤＢ制御処理は、派生ＤＢ（派生管理ＤＢと派生インデックスＤＢ）以外のＤＢを読み込まないため、デッドロックは生じない。
【０２０８】
再度図２５を参照して、本実施形態での派生トランザクション管理方法を説明する。派生トランザクション管理方法は、派生起動トランザクション（派生起動ＡＰＰＬ１１１Ａ）を実行すると共に、当該派生起動トランザクションによって起動要求依頼される派生トランザクション（派生受動ＡＰＰＬ１１３Ａ）のコミットを待機せずに当該派生起動トランザクションをコミットさせる派生起動トランザクション管理工程（１００Ａ，１１２Ａ）と、派生起動ＡＰＰＬ１１１Ａによって起動要求依頼された派生トランザクションを管理する派生トランザクション管理工程（派生特性管理共通処理１０４Ａ）と、この派生トランザクション管理工程にて派生トランザクションとして起動される派生ＤＢ管理工程（派生ＤＢ制御処理１１４Ａ）とを備えている。
【０２０９】
前記派生起動トランザクション管理工程は、当該派生起動トランザクションの一部として、当該派生起動トランザクションのＪＯＢ番号に応じて前記派生インデックスＤＢを参照し、前記派生管理ＤＢの派生管理通番を特定し、当該派生管理通番のセグメントに派生起動情報を格納し、当該使用した派生管理通番に対応する前記インデックスビット及び使用中フラグをそれぞれ使用中に更新して、当該派生トランザクションを起動させる派生要求共通処理工程（派生要求共通処理１１２Ａ）を備えている。
【０２１０】
そして、派生トランザクション管理工程は、前記派生トランザクションの一部として、派生要求共通処理工程１１２Ａにて派生トランザクションが起動されスケジュールされた場合に、当該派生トランザクションに与えられた派生管理通番をキー値として派生管理ＤＢを読み込み、当該派生管理通番の使用中フラグが使用中である場合には当該派生トランザクションのオペコードに応じた派生受動業務プログラムを実行させ、この派生受動業務プログラムが終了した後に前記派生管理ＤＢの使用中フラグをオフに更新して、さらに所定の派生ＤＢ制御処理を派生トランザクションとして起動させる派生特性管理共通処理工程（派生特性管理共通処理指令１０４Ａ）を備えている。この派生特性管理共通処理工程にて、インデックス・ビットマップの更新を行わないため、図２６に示すデッドロックが生じない。
【０２１１】
そして、派生ＤＢ管理工程は、前記派生ＤＢ制御処理がスケジュールされた場合に、前記派生受動業務プログラムを含む派生トランザクションを再起動するための派生起動情報が格納された派生管理ＤＢの派生管理通番に対応する前記派生インデックスＤＢの前記派生インデックスビットを使用可に更新する派生ＤＢ制御処理工程（派生ＤＢ制御処理指令１１４Ａ）を備える。派生ＤＢ制御処理工程では、１つのとして、インデックス・ビットマップの更新のみを行うため、他のトランザクションのロックの待機を行うことはあっても、デッドロックを生じることはない。また、派生ＤＢ制御処理による派生ＤＢ制御トランザクションは、図２５に示す例では、派生特性管理共通処理１０４Ａによって指定された派生管理通番にて派生管理ＤＢ７０を読み取るため、派生特性管理共通処理１０４Ａとの直列性を有する。すなわち、派生特性管理共通処理が正常にコミットした後に、インデックス・ビットマップを更新する。従って、並列処理によってシステム的な一貫性が失われることはない。
【０２１２】
また、図２４に示すように、第３実施形態においても総量制御部１４の各構成を備えるようにしても良い。第３実施形態では、システム負荷が大きい場合には、派生ＤＢ制御処理の起動を中止し、滞留の解消後に一括して派生インデックスビットをオフにする処理を行うようにしても良い。
【０２１３】
第３実施形態では、アボートされた派生トランザクションの再起動は、第２実施形態と同様である。業務メイン１００Ａ，派生起動ＡＰＰＬがアボートした場合には、使用中フラグ，派生インデックスビット共に使用可のままであり、派生トランザクションの起動要求もなされない。派生要求共通処理１１２Ａにて派生ＤＢ６８，７０の更新後、派生起動要求の出力前にアボートされた場合には、使用中フラグ及び派生インデックスビットは更新されるものの、ロールバックによってこの更新がなかったものとなる。そして、派生トランザクションもスケジュールされない。
【０２１４】
派生起動要求の出力後に派生要求共通処理１１２Ａや、業務メイン１００Ａや、派生起動ＡＰＰＬ１１１Ａが連動受動業務の場合で連動戻り後の連動起動業務の処理がアボートした場合にも、ロールバックによって派生要求共通処理のＤＢへの更新が無かったものとなる。しかし、派生メッセージはスケジュールされている可能性がある。この場合、派生特性管理共通処理１０４Ａ（３）にて使用中フラグをチェックする。使用中フラグを読み込めた時には派生起動トランザクションはアボートしている。このため、ロールバックによって更新されない状態の使用中フラグを読み取ることとなる。従って、派生特性管理共通処理１０４Ａ（３）では、使用中フラグが「使用可」であるため、派生受動ＡＰＰＬを呼び出さずに処理を終了する。この場合、派生起動トランザクションも派生トランザクションも無かったこととなる。
【０２１５】
派生起動トランザクションがコミットすると、使用中フラグが「使用中」の状態で派生管理ＤＢに耐久性を持って記録される。派生特性管理共通処理１０４Ａの（１）から（５）までと、派生受動ＡＰＰＬのアボートの場合、派生管理ＤＢの使用中フラグは使用中のままであり、派生インデックスＤＢも使用中のままである。派生受動ＡＰＰＬが完了後、派生特性管理共通処理が使用中フラグをオフにした後にアボートした場合や、さらに派生トランザクションを起動するための派生要求共通処理１１２Ａ等の処理中にアボートした場合には、ロールバックによって派生特性管理共通処理の更新が無かったものとなる。従って、使用中フラグは使用中（１）のままである。
【０２１６】
派生特性管理共通処理がコミットした後、派生ＤＢ制御処理がアボートしたとする。この場合、使用中フラグはオフとなっている。しかし、派生インデックスＤＢの派生インデックスビットはＯＮのままである。このように、（１）．派生起動トランザクションのアボートの場合には、派生トランザクションは起動しない。（２）．派生トランザクションがコミットしたが、派生受動ＡＰＰＬ１１３Ａや派生特性管理共通処理１０４Ａがアボートした場合には、使用中フラグ及び派生インデックスビットが共に使用中のままである。（３）．派生トランザクションもコミットしたが、派生ＤＢ制御処理１１４Ａがアボートした場合には、使用中フラグが使用可で、派生インデックスビットがＯＮの状態である。
【０２１７】
派生トランザクションの再起動が必要となるのは、（２）．の場合である。従って、使用中フラグがＯＮで、起動と一定時間が経過している処理を探索することで、再起動の要否を判定すべき派生トランザクションを特定することができる。（３）．の派生ＤＢ制御処理１１４Ａのアボートの場合には、派生受動ＡＰＰＬ及び派生特性管理共通処理１０４Ａは正常にコミットしているため、派生トランザクションを再起動する必要はない。
【０２１８】
上述したように本実施形態によると、派生と連動とが複雑に絡み合った状態で生じるデッドロックを派生ＤＢ制御処理によって回避することができるため、開発者がプログラム作成上の調整を行う必要がなくなる。
【０２１９】
【発明の効果】
本発明は、その構成によって、オンライン応答が必要なオンライントランザクションと、オンライントランザクション等に付随した処理を実行する派生トランザクションとに区分けされて実行される。このため、オンライン応答に必要な処理をオンライントランザクションとして処理し、オンライン応答に必要のない付随処理を派生トランザクションとしてオンライントランザクションのコミット後に処理する。従って、オンライントランザクションを早期にコミットさせることができる。これにより、オンラインの応答性を確保しつつ、付随的な業務のみを事後的に派生トランザクションとして処理することができる。従って、従来バッチ処理で行っていたような処理について派生トランザクションを利用してオンライントランザクションと並行した処理が可能となる。このように、本発明によると、派生トランザクションモデルを用いることで、従来バッチ処理等で実現していた処理や、１つのトランザクションとしては処理量が多くなる処理を実行しつつ、オンラインの応答性を確保することができる、というトランザクション制御システムを実現することができる。
【図面の簡単な説明】
【図１】図１は本実施形態によるオンライントランザクション制御システムの構成を示すブロック図である。
【図２】図２は、派生トランザクションの性質を説明する説明図であり、図２（Ａ）は、派生起動トランザクションから派生トランザクションの起動要求がなされる例を示す図で、図２（Ｂ）は、派生起動トランザクションが連動トランザクションである場合を示す図で、図２（Ｃ）は、派生トランザクションが自らを派生トランザクションとして起動要求する例を示す図である。
【図３】図３は派生トランザクションの利用法に応じた端末応答等を説明するための説明図であり、図３（Ａ）は、付随業務の場合を示す図で、図３（Ｂ）は取消再カットメインの場合を示す図である。
【図４】図４は、取消再カットメインの動作例を示す説明図である。
【図５】図５は端末折り返し連続処理に派生トランザクションを用いた例を示す説明図である。
【図６】図６は、トランザクションの総量制御の一例を示すフローチャートである。
【図７】図７は、第２実施形態の構成を示すブロック図である。
【図８】図８は、ＪＯＢと派生インデックスＤＢ等との関係を示す説明図である。
【図９】図９は、派生ＤＢのデータ項目を例示する説明図であり、図９（Ａ）は派生インデックスＤＢの項目例を示す図で、図９（Ｂ）は派生管理ＤＢの項目例を示す図である。
【図１０】図１０は、ＪＯＢ ＩＤと、派生インデックスＤＢのインデックス領域番号と、ビット位置と、派生管理通番との関係を例示する説明図であり、図１０（Ａ）はＪＯＢ ＩＤ０００で実行されているトランザクションによって読み出される派生インデックスＤＢとそのビット位置及び派生管理通番の関係を示す図で、図１０（Ｂ）はこの場合の派生管理ＤＢの内容の例を示す図で、図１０（Ｃ）はＪＯＢ ＩＤ００１で実行されているトランザクションによって読み出される派生インデックスＤＢとそのビット位置及び派生管理通番の関係を示す図で、図１０（Ｄ）はこの場合の派生管理ＤＢの内容例を示す図である。
【図１１】図１１は、派生トランザクションの要求を管理するための派生要求管理処理の一例を示すフローチャートである。
【図１２】図１２は、派生トランザクションの特性を管理するための派生特性管理処理の一例を示すフローチャートである。
【図１３】図１３は、オペコードテーブルの一例を示す図で、ここでは普通預金のオペコードテーブルを例示する。
【図１４】図１４は、取消再カットメインでの処理例を示す説明図であり、図１４（Ａ）は口座処理による電気料引落（内部自振）の取消を行う例を示す図で、図１４（Ｂ）はその処理による残高の推移を示す図である。
【図１５】図１５は、図１４に示した処理でのＦＩＦＯ推移及び派生メッセージの例を示す説明図である。
【図１６】図１６は、図１５に続くＦＩＦＯ等の推移を示す説明図である。
【図１７】図１７は、図１４及び図１５に示す例での派生ＤＢの利用例を示す説明図である。
【図１８】図１８は、ＪＯＢを一般トランザクションと派生トランザクションとに別々に割り当てる例を示す説明図である。
【図１９】図１９は、滞留監視処理の一例を示すフローチャートである。
【図２０】図２０は、派生トランザクションの実行を待機させる総量制御処理の例を示す図表である。
【図２１】図２１は、アボートされた派生トランザクションの再起動処理の一例を示すブロック図である。
【図２２】図２２は、派生トランザクションの再起動の要否を判定する処理の一例を示すフローチャートである。
【図２３】図２３は、派生トランザクションの再起動処理の一例を示すフローチャートである。
【図２４】図２４は、第３実施形態の構成を示すブロック図である、
【図２５】図２５は、派生管理処理の構成を示す説明図である。
【図２６】図２６は、派生ＤＢ制御処理を別トランザクションとしない場合に生じる可能性のあるデッドロックの態様の一例を示す説明図である。
【符号の説明】
２ 受信手段
４ 演算手段
６ ファイル
８ メッセージ入力手段
１０ オンライン応答部
１２ 派生トランザクション管理部
１４ 総量制御部
１６ トランザクション実行部
【発明の属する技術分野】
本発明は、トランザクション制御システム及びその方法に関する。
【０００２】
【従来の技術】
従来より、大規模なデータベースに対して正確で一貫性があり障害に対して確実な復旧を可能とする処理を実現する手法として、トランザクション処理が利用されている。トランザクションは、データベース（ＤＢ）に対する処理の単位として用いられる。トランザクションは、ＤＢに一又は複数の更新を行う。このとき、トランザクションは、その性質によって、全体として成功するか又は全体として失敗するかのいずれかであることが保証される。ＤＢへの全ての更新に成功した場合に、トランザクションは同期点(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）を意味する。先入れ先出し方式の略語としては用いない。ＦＩＦＯは、ＩＭＳ／ＥＳＡオンライン適用業務開発／運用支援プログラムであるＳＡＩＬによって提供される抽象化である。端末等からの全ての入力は、その業務に応じてＦＩＦＯという情報域に編集され、セットされる。このため、適用業務プログラムは、端末等から入力の形式によらず、予め定義したＦＩＦＯでの位置に特定の項目のデータがセットされている前提で開発することができる。すなわち、ＦＩＦＯを用いることで、入出力メッセージの形式によらず、適用業務プログラムを開発することができる。入出力メッセージとＦＩＦＯとは、編集定義を用いて関連させる。例えば、派生起動トランザクションが派生トランザクションを起動する場合には、派生トランザクションの実行に必要なデータをＦＩＦＯにセットし、派生起動要求依頼を行う。すると、ＳＡＩＬは、派生編集番号に従ってＦＩＦＯから派生メッセージを生成する。端末からの業務処理要求の入力や、端末への出力メッセージについても同様に業務毎の編集定義を用いる。
【０１２８】
図１０は、ＪＯＢ番号と、派生インデックスＤＢ６８のインデックス領域番号８８と、ビット位置と、符号８９で示す派生管理通番との関係を例示する説明図である。図１０（Ａ）に示すように、ＪＯＢ番号０００で実行されているトランザクションによって読み出されるインデックス・ビットマップの番号（インデックス領域番号）は、「０００」である。図１０（Ａ）に示す例では、ビット位置１及び５が使用中である。この場合、派生管理ＤＢの内容は図１０（Ｂ）に示す如くとなる。派生起動トランザクション側では、インデックス・ビットマップのビット（派生インデックスビットと呼ぶ）と、使用中フラグとは、原子性に包まれていることが望ましい。
【０１２９】
図１０（Ｃ）及び（Ｄ）に示すように、１つのインデックス・ビットマップが特定する派生管理通番の数Ｍが定められていると、インデックス領域番号８８とビット位置とに基づいて派生管理通番を特定することができる。
【０１３０】
図１１は、派生トランザクションの要求を管理するための派生要求管理処理の一例を示すフローチャートである。図１２は、派生トランザクションの特性を管理するための派生特性管理処理の一例を示すフローチャートである。図１１に示す派生要求共通処理は、派生起動トランザクションの一部として実行される。図１２に示す派生特性管理共通処理は、派生トランザクションの一部として、または別の処理として実行する。
【０１３１】
図１１を参照すると、派生要求共通処理は、派生起動トランザクションから派生起動要求依頼を受けると、まず、そのＪＯＢ番号（すなわち、インデックス領域番号）をキー値として派生インデックスＤＢを読み込む（ステップＳ５２）。そして、インデックス領域番号での残り個数フィールドをチェックし（ステップＳ５２）、空きがあれば、インデックス・ビットマップから空き（インデックスビットが０）のビット位置を特定する。ステップＳ５２にて空きが無い場合には、予備の派生インデックスＤＢを読み込み、残り個数フィールドをチェックする（ステップＳ６２）。予備の派生管理通番まで使用中である場合には、異常終了する。
【０１３２】
空きの派生インデックスビットを特定すると、そのビット位置に基づいて派生管理通番を算出する。そして、この派生管理通番を派生起動トランザクションが動作しているリージョンのＦＩＦＯにセットする。さらに、派生インデックスビットをＯＮ（対応する派生管理通番が使用中）を示す「１」に更新する（ステップＳ５４）。
【０１３３】
続いて、派生管理通番をキー値として、派生管理ＤＢを読み込み（ステップＳ５５）、派生インデックスＤＢ６８の残り個数フィールドと、派生件数フィールドとを更新する（ステップＳ５６）。そして、派生管理ＤＢに派生起動情報を登録し、派生管理ＤＢ７０の使用中フラグを「使用中」とする（ステップＳ５７）。続いて、派生トランザクションの起動を制御する（ステップＳ５８）。例えば、ＳＡＩＬは、派生起動トランザクションのＦＩＦＯから派生メッセージを生成し、待ち行列に登録する。続いて、派生起動トランザクションはコミットする。
【０１３４】
図１２は、派生トランザクションの開始及び終了時等の処理を示すフローチャートである。派生特性管理共通処理では、まず、派生トランザクションがいずれかのリージョンにスケジュールされると、まず、派生起動メッセージの派生管理通番をキー値として派生管理ＤＢ７０を読み込む。派生起動トランザクションがコミットしていない段階では、派生管理ＤＢ７０の当該派生管理通番のセグメントはロックされているため、ステップＳ７１では、派生起動トランザクションがコミット又はアボートし、このロックが解除されるまで待機する。
【０１３５】
派生トランザクションは、派生管理ＤＢの内容の読み出しに成功すると、まず、使用中フラグをチェックする。使用中フラグは、派生起動トランザクションによってステップＳ５７によって使用中を示す１に更新にされている。派生起動トランザクションがコミットした場合、この使用中フラグは「使用中」のままである。一方、派生起動トランザクションがステップＳ５８以後にアボートした場合、ロールバックによって、派生起動トランザクションによる使用中フラグの「使用中」への更新が取り消され、使用中フラグは使用可を示す０となっている。従って、ステップＳ７２では、使用中フラグが使用可の場合には、派生起動トランザクションがコミットした場合にのみ派生トランザクションがコミットするという派生トランザクションの性質に従って、派生トランザクションの適用業務プログラムを実行せずに終了する（ステップＳ７４）。
【０１３６】
派生起動トランザクションが正常にコミットしている場合、使用中フラグは「使用中」であるため、派生トランザクションの適用業務プログラムを呼び出し、実行を制御する（ステップＳ７５）。この適用業務プログラムの実行が完了すると、派生特性管理共通処理では、派生管理通番をキーとして派生管理ＤＢを読み込む（ステップＳ７６）。そして、使用中フラグを使用可に更新する（ステップＳ７７）。このとき、派生インデックスＤＢの派生インデックスビットも使用中のままとなっている。このため、派生トランザクションの一部として、又は別のトランザクションを用いて、派生インデックスＤＢ７８の派生インデックスビットをオフに更新する。この派生インデックスビットの更新に前後して、派生トランザクションはコミットする。
【０１３７】
また、図１２に示す派生特性管理共通処理によってその特性が管理される派生トランザクションが、別の派生トランザクションを起動する場合には、この派生トランザクションをコミットさせる前に、図１１に示す処理を実行する。
【０１３８】
ここで、図７に示す各機能と、図１１及び図１２に示す各工程との関係を説明する。図７に示すトランザクション管理システムの各機能１０１，１０２，１０３，１０４，１０５，１０６は、第１実施形態の場合と同様に、ＣＰＵが、派生管理通番特定機能１０１を実現するための派生管理通番特定指令や、派生起動情報格納制御指令などを実行することで実現できる。
【０１３９】
例えば、このプログラムは、オンライントランザクション又は派生トランザクションである派生起動トランザクションから派生トランザクションの起動要求依頼があったときに前記派生インデックスＤＢのインデックス情報を特定させると共に当該特定したインデックス情報に基づいて前記派生管理ＤＢの使用可の派生管理通番を特定させる派生管理通番特定指令を備えている。この指令を実行すると、ＣＰＵは派生管理通番特定機能１０１として動作する。図１１に示す例では、この派生管理通番特定指令を実行すると、ＣＰＵはステップＳ５１，５２，Ｓ５３及びＳ５４等の工程を実現する。
【０１４０】
また、このプログラムは、派生管理通番特定指令に応じて特定された派生管理通番のセグメントに前記派生起動トランザクションによる派生トランザクションの起動要求依頼に関する派生起動情報を格納させると共に当該派生起動情報を格納した後に当該派生トランザクションを起動させる派生起動情報格納制御指令を備える。ＣＰＵは、この指令を実行することで派生起動情報格納機能１０２として動作する。図１１に示す例では、ステップＳ５４，Ｓ５５，Ｓ５６，Ｓ５７の工程を処理する。
【０１４１】
プログラムは、さらに、派生起動情報の格納後で当該派生起動トランザクションの各処理が正常終了した場合に当該派生起動トランザクションをコミットさせる派生起動トランザクションコミット処理指令を備える。これにより、ＣＰＵは、派生起動トランザクションコミット処理機能１０３として動作する。ステップＳ１１では、最後の工程である。
【０１４２】
また、プログラムは、前記派生トランザクションの開始時に前記派生起動情報をロック可能な状態での正常な読み出しに成功した場合に当該派生トランザクションの各処理を開始させる直列性制御指令を備える。図１２に示す例では、これは、ステップＳ１２の派生起動情報の読み取り工程Ｓ７１によって、この直列性の制御を実現する。直列性制御指令を実行するＣＰＵは、直列性制御機能１０４として、図１２に示すステップＳ７１からＳ７５の処理を行う。
【０１４３】
派生トランザクション管理用プログラムはさらに、派生トランザクションの各処理が正常終了した場合に使用した派生管理通番について前記派生インデックスＤＢ及び前記派生管理ＤＢを使用可に更新させると共に当該派生トランザクションをコミットさせる派生トランザクションコミット処理指令を備える。この指令を実行するＣＰＵは、派生トランザクションコミット処理機能１０５として、図１２に示すＳ７６，Ｓ７７，Ｓ７８，Ｓ７９の処理を行う。第３実施形態では、デッドロックの発生を防止するために、派生トランザクションとは別のトランザクションとしてＳ７８及びＳ７９による派生インデックスＤＢの更新を行う。
【０１４４】
また、このプログラムは、派生トランザクションがアボートされた場合には前記派生管理ＤＢに格納した派生起動情報に基づいた再起動を制御する派生再起動制御指令を備える。この派生再起動制御指令を実行するＣＰＵは、派生再起動制御機能１０６として機能する。実際の再起動処理は、派生再起動制御部７７が行うようにしても良い。このように、図７に示す各部や図１１，図１２等のフローチャートに示す各工程は、それぞれの処理を行うプログラムを実行することによって実現できる。これは、総量制御処理や（図１９）、派生再起動要否判定処理（図２２）や、派生再起動制御処理（図２３）の各フローチャートに示す工程についても同様である。
【０１４５】
このように、図１１及び図１２に示す例では、派生インデックスＤＢ６８が、前記インデックス領域番号８８毎のビットマップを派生インデックスビットの列として有すると共に、当該派生インデックスビットのＯＮ又はＯＦＦに応じて当該ビットのビット位置に対応する派生管理ＤＢ７０の使用状態を記録している。そして、派生管理ＤＢ７０は、派生管理通番毎に当該派生管理通番の使用状態を使用中又は使用可として記録する使用中フラグを有する。
【０１４６】
さらに、派生管理通番特定機能１０１は、使用可を示すＯＦＦ（０）の派生インデックスビット及び使用可（０）の派生管理通番を特定したときに、当該派生インデックスビットについて使用中を示すＯＮ（１）へと更新する（ステップＳ５４）。続いて、派生起動情報格納制御機能１０２は、派生起動情報を格納したときに当該派生管理通番の使用中フラグについて使用中（１）へと更新する（ステップＳ５７）。そして、直列性制御機能１０４は、前記派生起動トランザクションから渡された派生管理通番の使用中フラグが使用可（０）であった場合には当該起動要求されている派生トランザクションを起動せずに処理を終了させ（ステップＳ７４）、派生トランザクションコミット制御機能１０５は、当該派生トランザクションの完了時又は完了後に前記派生インデックスビット及び前記使用中フラグについて使用可の状態（０）へと更新する（ステップＳ７７，Ｓ７９）。すなわち、派生インデックスビットをＯＦＦ（０）とし、使用中フラグを使用可（０）とする。
【０１４７】
このように、派生起動トランザクションと派生トランザクション間の派生起動情報のコンテンションを利用することで、派生トランザクションの性質を一般的なＤＢのロック機構を用いて実現することができる。
【０１４８】
次に、先日付完結処理システムでの取消再カットメインを例として派生トランザクション管理の一例を説明する。
トランザクションのコミットのタイミングをプログラム中に記述しない方が、そのプログラムの再利用性は高まる。このため、トランザクションの実行を管理するプログラムが、適用業務プログラム（ＡＰＰＬ）を呼び出し、実行し、正常に終了した段階でコミットを与える仕組みとすると、ＡＰＰＬを種々の態様で利用することができる。トランザクションの管理を行うプログラムを、ここでは業務メインと呼ぶ。また、ＡＰＰＬの実行形態として、端末から初回に入力された場合や、連続して繰り返し処理する場合や、連動処理として呼び出された場合や、派生トランザクションとして起動された場合や、センター一括処理として入力される場合などがある。これらの取引の態様が異なっても、プログラムの一部または全体が共通する場合がある。このため、プログラムを細分化しておき、起動の形態に応じて適切なプログラムを特定する仕組みとすると、プログラムの再利用性が高まり、全体の行数を少なくすることができる。
【０１４９】
図１３は、このような仕組みを提供するためのオペコードテーブルの一例を示す説明図である。業務処理要求や、派生トランザクションの内容は、オペコードで特定される。例えば、普通預金の出金処理のオペコードは０１００１である。そして、端末初回入力の場合には、プログラム０１，０２，０３をこの順に呼び出して実行する。同様に、連動処理の依頼を受けた場合には、プログラム０６，０７，０８をこの順に実行する。ＳＡＩＬは、業務処理要求（オペコードを含む）を受信すると、その業務に応じた編集定義を特定し、編集定義に基づいてＦＩＦＯを組み立てると共に、業務メインを呼び出す。業務メインは、オペコードテーブルのプログラムリストに従ってプログラム（ＡＰＰＬ）を呼び出す。
【０１５０】
さらに、業務メインは、派生トランザクションの起動要求依頼を受けた場合には、図１１に示す処理を実行するプログラムを呼び出す。一方、派生トランザクションの起動に際しては、派生トランザクションのオペコードによるＡＰＰＬの呼び出しの前後に、図１２に示す処理を実行する。
【０１５１】
図１３に示すように、普通預金出金のオペコードは、０１００１である。先日付完結処理システムでは、この普通預金出金は取り消されることがある。この取消については、すべてのオペコードについて一定値（図１３に示す例では、５００）を加算する体系としている。これにより、ある取引を取り消す場合にオペコードを探索する必要がなくなる。図１３に示すように、普通預金の出金は、定積入金（０３００１）や、定期入金（０４００１）から連動起動又は派生起動なされる。
【０１５２】
図１４は、取消再カットメインでの処理例を示す説明図であり、図１４（Ａ）は口座処理による電気料引落（内部自振）の取消を行う例を示す図で、図１４（Ｂ）はその処理による残高の推移を示す図である。図１４（Ｂ）に示すように、６日の残高が６０，０００で、７日を勘定日とした電気料の引落（自振通番１２３４５）２０，０００が先日付完結処理により実行され、７日の残高が４０，０００となっているとする。この状態で、ＡＴＭを用いて普通預金から定期預金への入金があると、定期入金処理Ｓ２１は、オペコード０１００１の普通預金出金Ｓ２２を連動起動する。普通預金出金では、６日の残高は６０，０００であるため、５０，０００の出金が可能であることから、５０，０００の出金を行い、成立した旨を定期入金に伝える（連動戻り）。
【０１５３】
定期入金では定期預金マスタ等に記録し、ＡＴＭに定期入金が完了した旨の応答を出力する。一方、普通預金出金Ｓ２２では、６日の残高の更新後に、先日付の勘定日である７日の残高も更新する。７日の残高は、マイナス１０，０００となる。普通預金出金Ｓ２２は、７日の残高がマイナスとなったことから、７日を勘定日として取消再カットメインを起動する。取消再カットメインは、出金可能額のマイナスが解消するまで７日にて成立している口座処理を取り消す制御をする。ここでは、電気料の引落を取り消しを起動する。ステップＳ２４では、電気料の引落の取消（オペコード０２００１＋５００＝０２５０１）を行い、普通出金の取消に連動する。普通出金の取消（オペコード０１００１＋５００＝０１５０１）は、２０，０００の出金の取消を行うため、７日の残高に２０，０００を加算する。そして、７日の口座残高に異動が生じたため、再度取消再カットメインを派生トランザクションとして起動する。取消再カットメインＳ２６は、図４に示す処理を行い、取消再カットの必要性がないことから、なんら起動せずに処理を終了する。
【０１５４】
図１４（Ａ）に示すように、定期入金と普通出金は連動しており、１つのトランザクションＴ１である。これが、リージョン０にスケジュールされ、ＪＯＢ番号が「０００」であるとする。普通出金が派生トランザクションの起動要求依頼をしたとき、トランザクションＴ１はコミットしていない。高速パス（ＦＰ）を用いたシステムでは、トランザクションＴ１のコミットの前に派生トランザクションがスケジュールされる。リージョン０は派生起動トランザクションＴ１によって使用されているため、派生トランザクションである取消再カットメインは、例えばリージョン１にスケジュールされる。この場合、取消再カットメインのＪＯＢ番号は「００１」となる。取消再カットメインＳ２３は、種々の判定処理を行った後に電気料引落の取消を派生トランザクションとして起動する。
【０１５５】
取消再カットメインＳ２３が派生起動トランザクションＴ２として電気料引落の取消処理を起動させたとき、定期入金及び普通出金のトランザクションＴ１は既にコミットしている可能性が高い。すなわち、派生起動トランザクションＴ１はその付随業務である取消再カットメインである派生トランザクションＴ２のコミットを待機せずにコミットする。トランザクションＴ１がコミットしていると、リージョン０は空いているため、電気料引落の取消を行う派生トランザクションＴ３は、リージョン０にスケジュールされることがある。
【０１５６】
図１５乃至図１７は、この状態での派生起動情報の格納及び派生メッセージの出力や、ＦＩＦＯの推移を説明するための説明図である。この例では、ＩＢＭ社のＭＶＳで動作するＩＭＳをＦＰで高速化し、さらにＳＡＩＬによるＦＩＦＯ及び編集定義を使用し、そして、業務メインによりオペコードテーブルを用いて各トランザクションを管理する。この例では、第２実施形態で説明している派生インデックスＤＢ及び派生管理ＤＢを用いている。
【０１５７】
業務メインは、ＡＴＭから定期入金の業務処理要求を、図１５の符号Ｍ１で示す入力メッセージの形式で受信する。入力メッセージＭ１中、Ｈはヘッダー、オペコードは定期入金を示す０４００１（図１３参照）、金額は５０，０００であり、ここでは、普通預金の店番２１１の口座２１ｙｙｙｙから出金して、２１０店番の口座３０００ｘｘｘｘｘに入金する処理を要求する。ＩＭＳは、入力メッセージＭ１を待ち行列から取り出すと、空いているリージョン０へスケジュールし、トランザクションを開始させる。ＳＡＩＬ及び業務メインは、図１７に示すように、このリージョン０内に、入力メッセージＭ１から所定の入力編集定義を用いて定期入金のＦＩＦＯ８６Ａを展開する。図１５に示すように、ＦＩＦＯ８６Ａには、予め定められた位置に、オペコードや、定期入金する店番や、入金金額等が格納される。そして、業務メインは、定期入金のオペコードテーブルを参照して所定のプログラムを呼び出し、実行させる。定期入金プログラムは、普通預金からの出金を依頼するために、オペコード０１００１への連動を起動する。このとき、連動編集定義に基づいて、普通出金用のＦＩＦＯ８６Ｂがセットされる。結果コードは、普通預金からの出金に成功するか否かを示すコードである。
【０１５８】
普通預金出金は、ＦＩＦＯにセットされた２００１／３／６を勘定日とする残高を参照し、出金が可能であるか否かを判定し、出金が可能であれば、６日の残高を１０，０００に更新する。そして、先日付の勘定日が存在するため、７日の残高も更新する。７日の残高がマイナスとなったため、取消再カットメインを処理する開始日（派生日付）を２００１／３／７にセットして、派生起動要求依頼を業務メインに渡す。例えば、派生起動のマクロを実行する。ＳＡＩＬは、普通出金ＦＩＦＯの内容から派生編集定義を用いて派生メッセージ（取消再カットメイン）Ｍ２を生成する。このとき、業務メインは、図１１に示す処理を呼び出す。図１１に示すように、呼び出された派生要求共通処理は、普通出金ＦＩＦＯの内容を派生管理ＤＢに格納する。この例では、ＪＯＢ番号が「０００」であるため、図１７に示すようにインデックス領域１のインデックス・ビットマップを読み取り先頭が「０」であったことから、派生管理通番を１とする。そして、このエントリー日付や時刻等と共に、図１５に示す普通出金ＦＩＦＯ８６Ｂの内容を派生管理ＤＢ７０の派生管理通番１のセグメントに記録する。普通出金ＦＩＦＯが記録された状態では、図１７に示すように、インデックス・ビットマップの先頭の派生インデックスビットがＯＮ（１）であり、また、派生管理通番１の使用中フラグが使用中（１）となる。
【０１５９】
図１５に示すように、普通預金の出金に成功すると、連動戻り編集定義を用いて、連動戻りブロックに出金に成功した旨を示す結果コード（００００）を記録する。定期入金処理は、定期入金に成功したため、定期入金ＦＩＦＯから出力編集定義を用いて出力メッセージを生成し、ＡＴＭに送信させる。これにより、ＪＯＢＦＰ０００のトランザクションＴ１はコミットする。
【０１６０】
ＩＭＳは、派生メッセージＭ２をリージョン１にスケジュールし、ＳＡＩＬは、派生メッセージから取消再カットＦＩＦＯ８６Ｄをセットする。取消再カットメインは、派生トランザクションであるため、業務メインは、まず図１２に示す処理を行う。すなわち、派生特性管理共通処理として、派生管理通番をキー値とした派生管理ＤＢの読み込みを行う。ここでは、派生管理通番１のセグメントを読み取る。すなわち、派生管理ＤＢ７０に格納された普通出金ＦＩＦＯ８６Ｂを読み出す。これにより、トランザクションＴ１のコミットを待機すると共に、Ｔ１のアボートの有無の確認を行う。普通出金を含むトランザクションＴ１が正常にコミットした後、ステップＳ７５に示すように、適用業務プログラムを呼び出す。ここでは、派生メッセージのオペコードである０５００１（取消再カットメイン）を構成するプログラムを呼び出す。取消再カットメインは、取消の対象を特定し、その自振通番（１２３４５６）や、取消金額等を取消再カットＦＩＦＯ８６Ｄにセットし、派生起動要求依頼を行う。業務メインは、図１１に示す派生要求共通処理を実行させる。このとき、取消再カットメインはＪＯＢ番号００１で動作しているため、図１７に示すように、派生管理通番は４０１となる。このため、ＦＩＦＯ８６Ｄの派生管理通番の項目を１から４０１へと更新し、このＦＩＦＯ８６Ｄを派生管理通番４０１のセグメントに格納する。そして、派生編集定義に従って、図１６に示す派生メッセージＭ３を生成する。
【０１６１】
派生メッセージＭ３は自振（電気料引落）の取消であり、オペコードは０２５０１である。トランザクションＴ３は連動取引を用いてこの自振取消を行い、連動受動業務である普通出金取消処理は派生メッセージＭ４を出力させる。このとき、トランザクションＴ３がリージョン０にスケジュールされたとする。
【０１６２】
図１７に示す例では、トランザクションＴ２の派生要求共通処理が派生メッセージを出力させた時点では、トランザクションＴ１がコミットしている。これは、派生起動トランザクションＴ１は派生トランザクションＴ２のコミットを待機せずに早期にコミットすることで、ここでは定期入金処理の応答性を確保していることによる。一方、派生メッセージ（自振取消）Ｍ３は、トランザクションＴ２がコミットする前にスケジュールされる。このため、自振取消を主業務とするトランザクションＴ３はリージョン０にスケジュールされた。トランザクションＴ３では、まず、取消再カットメインであるトランザクションＴ２のコミットを待機するために、派生管理通番４０１の派生管理情報を読み出そうとする。
【０１６３】
トランザクションＴ２がコミットすると、図１２に示すように、業務メインは、派生特性管理共通処理（Ｓ７６，Ｓ７７）をトランザクションＴ２の一部として実行する。さらに、Ｓ７８及びＳ７９もトランザクションＴ２の一部として実行する例では、インデックス領域１の先頭の派生インデックスビットがＯＦＦに更新された後に、派生トランザクションＴ２がコミットする。この場合、トランザクションＴ３が派生トランザクションを起動する時には、すでに派生管理通番１が空いている。
【０１６４】
図１７に示す例では、派生インデックスＤＢのＯＦＦ（対応する派生管理通番が使用可）への更新を別トランザクションとして起動する。この場合、ステップＳ７７が終了した段階でトランザクションＴ２はコミットする。このとき、トランザクションＴ３は派生管理通番４０１の読み出しに成功し、さらに普通預金出金取消が完了すると、再度取消再カットメインを起動しようとする。このとき、トランザクションＴ２によって起動された派生インデックスビットのＯＦＦへの更新処理（派生ＤＢ制御処理）が完了していないと、インデックス領域１の先頭の派生インデックスビットは１のままである。このため、次に空いているビット位置が２の派生インデックスビットを特定する。トランザクションＴ３からの派生起動情報は、普通出金取消ＦＩＦＯ等であり、これが派生管理通番２のセグメントに格納される。
【０１６５】
トランザクションＴ２によって起動された派生ＤＢ制御処理が当該インデックスビットを更新すると、インデックス領域１のインデックスビットの先頭ビットは０となる。このため、次にリージョン０で実行されるトランザクションが派生トランザクションを起動する場合には、派生管理通番１が利用される。このように派生管理通番を繰り返し利用するため、本実施形態では、派生管理ＤＢ及び派生インデックスＤＢの再編成処理が不要である。
【０１６６】
図１５乃至図１７に示す例では、各リージョンは、一般トランザクションと派生トランザクションの双方を実行するものとして説明したが、図１８に示すように、ＪＯＢ番号（リージョン）を一般トランザクションと派生トランザクションとに別々に割り当てるようにしても良い。図１８に示す例では、全てのＪＯＢが派生トランザクションによって使用されるという可能性がなくなるため、オンラインの応答性の悪化を防止することができる。そして、業務処理要求（メッセージ）の取り扱いを容易にするために、図１８に示す例では、オンラインシステムが、待ち行列１３として、オンライントランザクションやセンター一括処理の実行を要求するメッセージ（電文）を一時的に記憶する一般待ち行列１３Ａと、派生トランザクションの実行を要求する派生メッセージを一時的に記憶する派生待ち行列とを備えている。２種類の待ち行列を併用することで、トランザクションの総量制御が容易となる。
【０１６７】
＜総量制御＞
再度図７を参照すると、オンラインシステム（または、トランザクション制御システム）は、図１８に示す一般待ち行列１３Ａ及び派生待ち行列１３Ｂで滞留しているトランザクション数を監視する滞留監視部７８と、この滞留監視部７８によって監視される各待ち行列でのトランザクションの滞留数に応じて前記派生起動トランザクション又は前記派生トランザクションの起動を制御する総量制御部７９とを備えている。
【０１６８】
図１９は、滞留監視処理の一例を示すフローチャートである。滞留監視部７８は、前記一般待ち行列又は派生待ち行列の滞留数が予め定められた第１レベル以上である場合には（ステップＳ８１，Ｓ８３）、派生起動取引中断ビットをＯＮとする（ステップＳ８２，Ｓ８４）。図１９に示す例では、それぞれの待ち行列１３Ａ，１３Ｂに格納されたメッセージ数が２００を越えた場合に、派生起動取引中断ビットをＯＮとしている。そして、前記派生待ち行列に滞留しているトランザクション数が前記第１レベル（２００）よりも多い数にて予め設定された第２レベル（５００）以上である場合には（ステップＳ８５）、派生中止ビットをＯＮとする（ステップＳ８６）。一方、上記各ビットがＯＮとなった後に、それぞれの待ち行列の滞留数が０となった場合には（ステップＳ８７）、各ビットをＯＦＦとする（ステップＳ８８）。この滞留監視部７８による監視処理は、所定の監視時間間隔で、例えば３０秒ごとに繰り返し実行する。滞留監視部７８は、派生起動取引中断ビットや、派生中止ビットを図７に示すシステム状況ＤＢ８３に格納する。
【０１６９】
図２０は、派生トランザクションの実行を待機させる処理の一例を示す図表である。総量制御部７９は、前記派生起動取引中断ビットがＯＮである場合には前記派生トランザクションを起動する業務処理要求の入力を中断させる派生起動取引入力中断制御機能２８を備える。派生トランザクションを起動する業務処理要求としては、例えばセンター一括処理がある。派生起動取引入力中断制御機能２８は、本実施形態では、例えば、センター一括処理を要求するセンターカット電文を入力するとき（例えば、ＳＡＩＬのＥＸＩＴ処理時）、システム状況ＤＢ８３に格納された派生起動取引中断ビットを参照し、派生起動取引中断ビットがＯＮであると、センターカット電文の入力を中断する。従って、センター一括処理自体を待機させることでシステム負荷を軽減し、且つ、センター一括処理は取消再カットメインを派生トランザクションとして起動する可能性があるため、派生トランザクションの起動を抑制することができる。
【０１７０】
また、総量制御部７９は、システム状況ＤＢ８３に格納された派生中止ビットがＯＮである場合に、派生起動要求があった時には、当該派生起動情報を前記派生管理ＤＢに登録後、派生トランザクションの起動を行わない派生起動中止制御機能３０を備える。図１８に示す例では、派生起動トランザクションを管理する派生起動要求共通処理は、派生起動情報を登録後、派生中止ビットがＯＮである場合には、派生メッセージを出力しない。すると、派生起動トランザクションがコミットし、派生トランザクションがアボートされたのと同様の状態となる。すなわち、派生起動中止制御機能３０は、派生メッセージの出力処理時にシステム状況ＤＢ８３の派生中止ビットを参照し、派生中止ビットがＯＮである場合には付随処理である派生トランザクションを起動しない。
【０１７１】
また、総量制御部７９は、前記派生中止ビットがＯＮである場合に業務処理要求を受信した場合であって、当該業務処理要求に滞留時停止指定がある場合には、当該業務処理要求の処理を不能としてエラー出力する滞留時エラー制御機能３１を備えるようにしても良い。図１３を参照すると、動作環境指定として、オペコードに続いて滞留＝Ｎｏ，センター一括＝Ｙｅｓ等の指定がある。この動作環境指定で滞留＝Ｙｅｓとなっているオペコードの処理を要求されたときに、派生中止ビットがＯＮとなっている場合には、滞留時エラー制御機能３１を備える例では、当該メッセージを処理不能としてエラーを出力する。
【０１７２】
＜派生再起動＞
次に、派生トランザクションの再起動について説明する。派生トランザクションは、アボートされた場合や、派生トランザクション実行中にシステム障害が発生した場合や、派生トランザクションの起動が中止された場合に、事後的に再起動を行う。派生トランザクションの再起動の手順を明確にすることで、派生起動トランザクションと派生トランザクションとを利用した派生利用トランザクションの実際上の原子性を保つことができる。
【０１７３】
再度図７を参照すると、演算手段４は、前記派生インデックスＤＢ６８及び派生管理ＤＢ７０を参照して派生インデックスビット及び使用中フラグがＯＮで且つ派生管理ＤＢに派生起動情報を格納した後予め定められた時間以上経過している派生管理通番を派生再起動要と判定する派生再起動要否監視部７６と、派生再起動要否監視部７６によって再起動要と判定された派生管理通番を再起動する場合には、当該派生管理通番によって特定される派生起動情報に基づいて派生トランザクションを起動すると共に当該派生管理通番へ派生起動情報を格納した時刻を更新する派生再起動制御部７７とを備えている。
【０１７４】
まず、アボートの態様を説明する。派生起動トランザクションがアボートした場合、派生起動情報が一旦格納されていたとしてもロールバックによりその更新が無効となるため、派生管理通番の使用中フラグがオフとなる。このため、派生トランザクションは起動しない（図１２，Ｓ７４）。従って、派生起動トランザクションのアボートでは派生トランザクションの再起動が必要となることはない。
【０１７５】
派生トランザクションがアボートした場合、使用中フラグを使用可に更新していたとしても、この使用可への更新はロールバックにより取り消される。従って、派生トランザクションの原子性により、派生トランザクションがアボートした場合には使用中フラグが使用中となっていることが保証される。従って、派生再起動要否監視部７６は、派生インデックスビット及び使用中フラグがＯＮで且つ派生管理ＤＢに派生起動情報を格納した後予め定められた時間以上経過している派生管理通番を派生再起動要と判定することができる。デッドロックの発見に処理開始後の経過時間による判定が極めて有効であるのと同様に、本実施形態では、派生トランザクションのアボートの判定に派生起動情報のエントリー後の経過時間を用いることで、確実に派生トランザクションのアボートを検索する。
【０１７６】
また、派生トランザクションの終了処理にて、派生インデックスビットを派生ＤＢ制御処理にて実行する場合、この派生ＤＢ制御処理がアボートしたときには、派生トランザクションによる使用中フラグの更新は成功し、すでにコミットしているため、使用中フラグがオフで、派生インデックスビットがＯＮとなる。この場合、派生トランザクションの付随業務の内容は正常にコミットしているため、派生トランザクションを再起動する必要はない。
【０１７７】
派生再起動制御部７７は、派生再起動要否監視部７６によって再起動要と判定された派生管理通番を再起動する場合には、当該派生管理通番によって特定される派生起動情報に基づいて派生トランザクションを起動すると共に当該派生管理通番での派生起動情報を格納した時刻を更新する。本実施形態では、自動的な再起動を行うのではなく、アボートした派生トランザクションの存在をオペレータに表示し、オペレータからの再起動の要求を待って再起動処理を行う。このとき、派生再起動制御部７７は、派生トランザクションの再起動時にエントリー時刻を更新する。
【０１７８】
図２１は、派生トランザクションの再実行を派生管理業務により行う構成を示すブロック図である。コンソール端末２Ａから派生再実行要求９０を受信すると、そのコマンドを解析し、特定の派生トランザクションを再起動するか、又は、アボートした全派生トランザクションを一括して再起動するかの判定を行う。派生管理通番で指定された一件の派生トランザクションを再起動する場合、派生管理業務９２は、派生管理通番から派生管理ＤＢに格納されているＦＩＦＯを特定し、このＦＩＦＯを派生管理業務９２のＦＩＦＯへセットする。そして、この派生管理業務のＦＩＦＯに基づいて派生トランザクションの起動処理を行う。派生受動業務９３として、派生トランザクションが再起動される。
【０１７９】
全トランザクションを再起動する場合、派生管理業務９２は、予め定められた数の派生トランザクションを起動すると、図２（Ｃ）に示すような形式で、派生管理業務９５を派生起動する。派生管理業務９５も、予め定められた数の派生トランザクションを起動すると、派生管理業務を派生トランザクションとして起動する。各派生管理業務が予め定められた数の再起動しか行わないのは、１つのＪＯＢ番号から起動できる派生トランザクションの数が派生管理通番の数である図８乃至図１０に示すＭ（例えば、４００＋予備）以下に制限されるためである。
【０１８０】
図２２は、派生再起動要否監視部７６による派生再起動要否判定処理の詳細構成を示すフローチャートである。この派生再起動要否判定処理は、アボートされ、且つ再起動が必要な派生トランザクションの有無を監視する処理である。この派生再起動要否判定処理は、コンソール端末２Ａからのコマンド入力により実行する。また、一定時間間隔で自動的に起動するようにしても良い。コマンド入力により実行する場合、日付変更を行う前や、また、ある処理の終了時刻の前などに実行する。また、トランザクションがアボートされるとコンソール端末２Ａにその旨が表示されるため、この表示があったときに実行するようにしても良い。
勘定系システムを例とすると、例えば他の金融機関への振込処理はある時間までに完了させなければならないため、この為替の中断を指示する為替中断コマンドの入力前に、この派生再起動要否判定処理を実行することでアボートされた派生トランザクションの有無の確認を行う。例えば、上述した承認通知処理は派生トランザクションを利用するが、この派生トランザクションがアボートされていないことを確認する。また、日付変更時には再起動が必要な派生トランザクション（付随処理）が一件もないことが必要であるため、この日付変更コマンドの入力前に派生再起動要否判定処理をコマンド入力により起動する。
図２２を参照すると、派生再起動要否監視部７６は、まず、対象インデックス領域番号を０にセットする（ステップＳ９１）。続いて、派生インデックスＤＢ７８のインデックス・ビットマップを「読み取りのみ」のモードで読み込む（ステップＳ９２）。これは、通常の派生起動トランザクションとのインデックス・ビットマップに関するコンテンションの発生を防止するためである。続いて、インデックスビットの位置を先頭（１番目）にセットする（ステップＳ９３）。そして、セットされた位置のビットを読み取り、この派生インデックスビットがＯＮ（使用中）であるか否かを判定する（ステップＳ９４）。派生インデックスビットがＯＮであれば、派生管理ＤＢの内容を読み取る（ステップＳ９５）。そして、派生起動情報のエントリー時刻を参照し、派生取引起動時刻から３０秒以上経過しているか否かを判定する（ステップＳ９６）。３０秒以上経過している場合には、再派生不要ビットがＯＮか、又は派生管理ＤＢの使用中フラグが使用可（０）であるか否かを確認する（ステップＳ９７Ａ）。
再派生不要ビットは、例えば端末折り返し連続処理などでＯＮとされている。派生インデックスビットが使用中で、派生管理ＤＢの使用中フラグがＯＦＦであるのは、派生トランザクションがコミットし、派生ＤＢ制御処理がアボートした場合であるため、派生トランザクションの再起動は不要である。ステップＳ９７Ａでノーであれば、その派生管理通番で起動された派生トランザクションについて再派生が必要と判定し、コンソール端末２Ａに、派生管理通番や、起動業務の識別コードや、派生受動業務のオペコードや、派生起動情報のエントリー日付及び時刻や、当初の業務処理要求の入力店番や端末番号や、さらに、派生取引対象口座の店番や口座番号等を出力する（ステップＳ９７Ｂ）。この再派生関連情報を参照して、オペレータは、当該派生管理通番で管理される派生トランザクションを再起動するか否か判定する。
【０１８１】
派生インデックスビットがＯＦＦである場合や（ステップＳ９４，ノー）、ＯＮであったとしても派生取引起動時刻から３０秒以上経過していない場合には（ステップＳ９６，ノー）ステップＳ９８Ａ，Ｓ９８Ｂを経由して次のインデックスビット（次の派生管理通番）の判定を行う。そして、派生取引起動時刻から３０秒以上経過していても、再派生不要ビットがＯＮであったり、また、派生トランザクションがコミットしたものの派生ＤＢ制御処理がアボートした場合（派生管理ＤＢ７０の使用中フラグが使用可）であるときも（ステップＳ９７Ａ，イエス）、次のインデックスビットの判定を行う。
ステップＳ９８Ａでは、インデックスビット位置が最終であるか否かを確認する。最終位置でなければ、ビット位置を１つずらして対応する次の派生管理通番を処理対象にセットし（ステップＳ９８Ｂ）、ステップＳ９４に処理を移す。一方、インデックスビットの位置が最終であれば、次のリージョンに対応するインデックス領域番号を判定対象とするため、対象インデックス領域番号に１を加算してセットし、ステップＳ９２に処理を移す。一方、ステップＳ９９Ａにて、すべてのインデックス領域（リージョン）の探索が完了している場合には、この派生再起動要否判定処理を終了する。
【０１８２】
図２３は、アボート又は起動中止された全ての派生トランザクションを一度のコマンドで順に再起動する処理例を示すフローチャートである。図２３に示す例では、派生再起動制御部７７は、まず、初回起動時に対象インデックス領域番号として０をセットする（ステップＳ１０１）。続いて、対象インデックス領域番号のインデックス・ビットマップのうち、使用中のビット位置を探索する（ステップＳ１０２）。使用中のビットがある場合には、その対象インデックス領域番号とビット位置とから派生管理通番を算出し、派生管理ＤＢに格納された内容を読み込む（ステップＳ１０３）。そして、使用中フラグがＯＮ（使用中）で、且つ派生トランザクションの起動時刻（派生起動情報のエントリー時刻）から５分以上経過しているか否かを判定する（ステップＳ１０４）。５分以上の経過がなければ、次に使用中である派生インデックスビットを探索する（ステップＳ１０２）。
【０１８３】
派生管理ＤＢの使用中フラグが「使用中」で、且つ派生起動情報のエントリーから５分以上経過している場合には、派生管理ＤＢ７０に格納されている派生起動情報に基づいて派生トランザクションの起動を制御する（ステップＳ１０５）。具体的には、派生管理ＤＢ７０に格納されたＦＩＦＯをセットし、派生管理ＤＢ７０に格納された派生編集番号に応じて当該ＦＩＦＯから派生メッセージを生成する。派生起動制御を行うと、再派生処理回数をインクリメントする（ステップＳ１０６）。そして、派生取引起動時刻を現時刻に変更して派生管理ＤＢを更新する。続いて、次の使用中のインデックスビットを探索する（ステップＳ１０２）。対象インデックス領域番号のインデックス・ビットマップを全て確認した場合には（ステップＳ１０２）、次の派生インデックスビットについて検討するため、対象インデックス領域番号に１を加算してセットする（ステップＳ１０８）。このとき、再派生処理回数（起動した派生トランザクションの数）が一定数（例えば、８０）を越えている場合には、再派生処理回数を０にクリアして、派生再起動処理を派生トランザクションとして起動する（ステップＳ１１１）。再起動された派生再起動処理では、初回起動時ではないためステップＳ１０１をパスし、セットされたインデックス領域番号のインデックス・ビットマップの派生トランザクションの再起動を検討する。
【０１８４】
ステップＳ１０８にて、再派生処理回数が一定数を越えていない場合には、全てのインデックス領域番号（インデックス・ビットマップ）の探索が完了したか否かを確認し（ステップＳ１１０）、未検討のインデックス・ビットマップが残っている場合には、対象インデックス領域番号に１を加算して、ステップＳ１０２に処理を移す。これにより、全てのインデックス・ビットマップについてアボートされた派生トランザクションの有無を探索することができる。
【０１８５】
上述したように第２実施形態によると、派生インデックスＤＢをＪＯＢ番号毎にアクセス可能とし、さらに、派生起動情報を派生管理ＤＢに格納するため、並列に処理されているトランザクション間のコンテンション防止し、デッドロックの発生を防止し、さらに派生管理ＤＢの再編成不要としつつ、一般的なＤＢのロック機構を用いて派生トランザクションの特性を管理することができる。
【０１８６】
【第３実施形態】
図１２に示す派生特性管理共通処理にて、ステップＳ７９を派生トランザクション内の処理とすると、デッドロックが発生する可能性がある。このデッドロックは、プログラムの構築の仕方によって回避することができるが、その回避のために適用業務プログラムのプログラマが留意すべき事項は、複雑である。このため、第３実施形態では、第２実施形態を拡張するものとして、派生ＤＢを用いつつもデッドロックの発生を回避することができる仕組みを開示する。具体的には、ステップＳ７９を派生トランザクションとは別のトランザクション（派生ＤＢ制御処理）として実行するものである。
【０１８７】
図２４は、本実施形態の構成を示すブロック図である。図２４に示すオンラインシステムは、ＡＴＭ等の端末１Ａ及び営業店端末１Ｂからネットワークを介して入力される業務処理要求を受信すると共に、コンソール端末２Ａから入力される業務処理要求（コマンド）を受信する受信手段２と、この受信手段２にて受信した業務処理要求をオンライントランザクションとして処理する演算手段４と、この演算手段４による業務処理要求の結果を記録するファイル６とを備えている。
【０１８８】
そして、ファイル６は、前記オンライントランザクション又は所定の派生トランザクションである派生起動トランザクションの実行の一部として起動される派生トランザクションの派生起動情報を派生管理通番毎に記録すると共に当該派生管理通番が使用中であるか否かを示す使用中フラグを有する派生管理ＤＢ７０と、この派生管理ＤＢ６８での派生管理通番を前記トランザクションのＪＯＢ番号を単位とした複数の派生管理通番から使用可の派生管理通番を特定すると共に前記派生管理通番が使用中であるか否かを示す派生インデックスビットを前記ＪＯＢ番号毎に複数有する派生インデックスＤＢ６８とを備えている。この派生インデックスＤＢ及び派生管理ＤＢ７０の構成及び役割については、上記第２実施形態と同様である。従って、好ましい例ではＪＯＢ番号からインデックス・ビットマップを特定し、このインデックス・ビットマップを参照して使用可の派生管理通番（派生インデックスビットのビット位置）を特定する。
【０１８９】
図２４に示す例では、演算手段４が、前記オンライントランザクション又は派生トランザクションの種類を特定するオペコードに応じて当該トランザクションを構成するプログラムの実行を管理する業務メイン処理部１００と、この業務メイン処理部１００によって呼び出されたプログラムを実行する業務処理部１１０とを備えている。ここでは、演算手段４の構成を、実際のプログラムの配分に従って、各プログラムをトランザクションとして管理する業務メイン処理部１００と、実際にプログラムを実行する業務処理部１１０とに機能分けをする。
【０１９０】
演算手段４では、ＩＭＳ上でＦＰ及びＳＡＩＬが各種のサービスを提供しているとする。図２４に示すメッセージ入力手段８（例えば、ＳＡＩＬの入力インタフェース）は、業務処理要求（入力メッセージ）を受信すると、入力メッセージ上の業務識別コード、媒体タイプ、入力編集番号をもとに入力編集定義テーブルを特定する。本実施形態では、業務識別コードと入力編集番号とはオペコードから変換する。入力インタフェースは、入力編集定義テーブルに従って、メッセージ上のデータを指定された編集を行い、編集後のデータを指定されたＦＩＦＯのフィールドへセットする。この編集の完了後、ＳＡＩＬは業務識別コードに対応した適用業務プログラムを呼び出す。本実施形態では、全業務に共通の業務メインと呼ばれるプログラムを呼び出す。
【０１９１】
業務メイン処理部１００は、図２５に示すように、業務メインの（１）開始処理を実行する。そして、例えば図１３に示すようなオペコードテーブルに基づいて適用業務プログラムを特定し、呼び出す。図２５に示す例では、業務メインは、派生起動トランザクションの一部となる派生起動ＡＰＰＬを呼び出す。すると、業務処理部１１０は、この派生起動ＡＰＰＬを実行する。この実行中に、業務処理部１１０は、派生起動要求依頼（マクロを用いる場合には、派生要求マクロ）を業務メインに入力する。
【０１９２】
業務メインは、派生起動要求依頼を受信した場合には、派生要求共通処理を呼び出す。すなわち、業務メイン処理部１００は、派生起動トランザクションの実行によって派生起動要求依頼を受信した場合には派生要求共通処理を当該派生起動トランザクションの一部として実行する派生要求共通処理呼び出し機能１０２を備えている。派生要求共通処理は、例えば図１１に示す処理である。業務処理部１１０は、この派生要求共通処理を実行する派生要求共通処理機能１１２を備える。派生要求共通処理機能１１２は、例えば、ＣＰＵが、図２５に示す派生要求共通処理指令１１２Ａを実行することで実現する。
【０１９３】
派生要求共通処理機能１１２は、図２５に示すように、派生要求共通処理が呼び出されて処理を開始すると（１）、当該派生起動ＡＰＰＬ１１１Ａがスケジュールされているリージョンでの当該トランザクションのＪＯＢ番号を特定し（２）、前記派生インデックスＤＢを参照する（３）。この参照により、前記派生管理ＤＢの派生管理通番を特定して派生インデックスビットをＯＮ（使用中）にする（４）。そして、ビット位置から派生管理通番を算出し、これを当該リージョン内のＦＩＦＯにセットする（６）。そして、派生インデックスＤＢ６８の残り個数及び派生件数を更新する（７）。さらに、派生管理通番のセグメントに派生起動情報を格納し、使用中フラグを使用中に更新する（８）。そして、派生要求共通処理は、システム状況ＤＢ８３に格納された派生中止ビットを参照し、派生中止ビットがＯＦＦであればＳＡＩＬ（ＯＳの一部）に派生起動要求（派生要求マクロ）を入力する（９）。その後、業務メインに戻る（１０）。派生中止ビットがＯＮであれば、派生要求マクロを入力せず、派生起動トランザクションをコミットさせる。
【０１９４】
派生要求マクロが出力されると、ＳＡＩＬの連動インタフェースは、起動業務識別コード・プログラムで指定した受動業務識別コード・編集番号から、派生編集定義テーブルを特定する。本実施形態では、受動業務識別コードと派生編集番号は派生受動処理（派生トランザクション）のオペコードから変換する。連動インタフェースは、派生編集定義テーブルに従って、指定された派生起動業務側ＦＩＦＯ上のデータを、指定された編集を行って派生メッセージへセットする。連動インタフェースは、派生メッセージを受信すると、入力メッセージ上の起動業務識別コード・受動業務識別コード・派生編集番号をもとに派生編集定義テーブルを特定する。連動インタフェースは、派生編集定義テーブルに従って、派生メッセージ上のデータを、指定された編集を行った後指定されたＦＩＦＯのフィールドへセットする。この編集完了後、ＳＡＩＬは業務メインを呼び出す。これにより、派生トランザクションの処理が開始される。呼び出された業務メインは、図２５に示す例では、派生特性管理共通処理指令１０４Ａを実行する。
【０１９５】
図２５に示す本実施形態では、「派生特性管理共通処理１０４Ａ」は、例えば図１２に示す処理のうち、派生インデックスビットを使用可に更新する処理を除いた部分である。図２４及び図２５に示す例では、業務メイン処理部１００が派生特性管理共通処理１０４Ａを実行する派生特性管理共通処理機能１０４を備える。
【０１９６】
派生特性管理共通処理機能１０４は、図２５に示すように、派生特性管理共通処理１０４Ａを開始すると（１）、まず、派生管理通番をキー値として派生管理ＤＢの読み込みを試みることで（２）、派生起動トランザクションとの直列性を保つ。派生管理情報の読み込みに成功すると、使用中フラグをチェックする。使用中フラグがＯＦＦであれば、派生起動トランザクションがアボートされたとして、派生受動ＡＰＰＬを呼び出さずに業務メインを終了する（４）。一方、この派生管理通番の使用中フラグが使用中である場合には、当該派生トランザクションのオペコードに応じた派生受動業務プログラムを呼び出して実行させる（４）。
【０１９７】
業務処理部１１０は、派生受動ＡＰＰＬを実行し、終了すると、業務メインに処理を戻す。派生特性管理共通処理は、派生受動ＡＰＰＬが終了した後に、前記派生管理ＤＢの使用中フラグをオフに更新して（６）、さらに所定の派生ＤＢ制御処理を派生トランザクションとして起動させる（７）。ＳＡＩＬは、派生トランザクションのＦＩＦＯを参照して所定の編集定義に基づいて派生メッセージを出力する。派生メッセージがスケジュールされると、派生ＤＢ制御処理が実行される。
【０１９８】
前記業務処理部１１０は、派生インデックスビットを使用可へと更新する派生ＤＢ制御処理を派生トランザクションとはさらに別のトランザクションとして実行する派生ＤＢ制御処理機能１１４を備えている。派生ＤＢ制御処理機能１１４は、ＣＰＵが派生ＤＢ制御処理指令１１４Ａを実行することで実現する。派生ＤＢ制御処理１１４Ａでは、まず、派生管理通番から派生インデックスＤＢ６８のインデックス領域番号とビット位置とを算出する（２）。そして、算出したインデックス領域番号をキー値として派生インデックスＤＢ６８のインデックス・ビットマップを読み込む（３）。続いて、派生管理通番をキー値として派生管理ＤＢ７０を読み込む（４）。この派生管理ＤＢの読み込みにより、派生特性管理共通処理１１２Ａとの直列性が維持される。そして、派生管理ＤＢの使用中フラグがＯＦＦであるか否かを確認し、ＯＦＦの場合に派生インデックスビットをＯＦＦ（使用可）にして派生インデックスＤＢを更新する。
【０１９９】
図２６は、派生トランザクションの一部として、派生トランザクションの完了時に派生インデックスＤＢの派生インデックスビットをＯＦＦとした場合に、生じる可能性があるデッドロックの一例を示す説明図である。すなわち、派生インデックスＤＢ６８を用いて派生管理通番を特定する派生ＤＢ制御処理を派生トランザクションと別のトランザクションとしない場合に生じる可能性のあるデッドロックの態様の一例を示す図である。
【０２００】
デッドロックは、２つのトランザクションが相互に相手方の処理の完了を待機する場合に生じる。例えば、トランザクションＴ１がＤＢｘを読み込み、これをロックした後、次に派生インデックスＤＢ６８を読み込もうとする。一方、トランザクションＴ２が派生インデックスＤＢ６８を読み込み、これをロックした後、次にＤＢｘを読み込もうとしたとする。トランザクションＴ１が派生インデックスＤＢ６８を読み込もうとしたときに、この派生インデックスＤＢ６８がトランザクションＴ２によってロックされている場合に、トランザクションＴ１とＴ２はデッドロックとなる。
【０２０１】
図２６に示す例では、まず、ＪＯＢＦＰ０００から派生起動要求が出力され、この派生トランザクションＴ２はＪＯＢＦＰ００１にスケジュールされた。トランザクションＴ２では、別のオペコードに連動するが、連動先ではあるＤＢｘをキーｙで読み込む。トランザクションＴ２は連動処理が完了してから、派生トランザクションの後処理（派生特性管理共通処理）として、派生管理ＤＢの使用中フラグをＯＦＦとし、派生インデックスＤＢの派生インデックスビットをＯＦＦとする。このとき、派生インデックスＤＢのキー値は、インデックス領域番号であるから、トランザクション１のＪＯＢ番号である０がキー値となる。派生管理ＤＢのキー値（派生管理通番）は、ここでは１とする。
【０２０２】
トランザクションＴ２の処理中に、トランザクションＴ３がＪＯＢＦＰ０００でスケジュールされた。トランザクションＴ３では、別オペコードに連動するが、連動先では派生トランザクションを起動するため、派生インデックスＤＢをキー値を０として読み、派生管理ＤＢの派生管理通番１のセグメントに派生起動情報を格納する。トランザクションＴ３では、連動処理が完了してから、ＤＢｘを読み込む。
【０２０３】
さて、トランザクションＴ２では、ＤＢｘを読み取った後、派生インデックスＤＢをキー値０として読み取ろうとする。トランザクション３では、派生インデックスＤＢを読み取った後、ＤＢｘを読みに行く。このため、トランザクションＴ２にて連動受動処理がＤＢｘを読み込んでロックした後、派生インデックスＤＢを読み取る前のタイミングで、トランザクションＴ３が派生インデックスＤＢを読み取ると、デッドロックとなる。また、トランザクションＴ３が派生インデックスＤＢを読み取った後、連動処理が完了してＤＢｘを読み取る前のタイミングで、トランザクションＴ２がＤＢｘを読み取ると、デッドロックが生じる。
【０２０４】
デッドロックの発生を完全に防止する手法は、並列処理を行わないことであるが、これは採用できない。ロックに関しては、並列処理の直列化を維持するために、あるトランザクションは、ロックを取得するフェーズと、ロックを解放するフェーズとの２相ロッキングプロトコルに従う必要がある。従って、一度ロックを解放すると、そのトランザクションはロックを取得してはならない。この２相ロッキングプロトコルの要件によると、デッドロックが生じた場合には一方のトランザクションをアボートしなければならない。
【０２０５】
デッドロックを回避しつつ、並列性も維持する方法は、トランザクションのロックの順序を調整することである。例えば、全てのトランザクションが同一の順序でロックを要求すれば、デッドロックを回避することができる。しかし、これはプログラマにとって厳しい制限となる。また、トランザクションが使用する全てのロックをその開始時に取得してから、実際の処理を行うことによっても、デッドロックの発生を回避することができるが、この場合、限りなく直列処理に近くなり、並列処理の利点が減少する。
【０２０６】
これらの標準的な手法でデッドロックを回避するためには、「派生トランザクションを起動する可能性がある連動受動処理に連動する前に、連動後に読むＤＢを連動前に読んでおく」必要がある。これにより、実行順序が同一となる。全ての連動起動処理がこの条件を満たすのであれば、図２６に示すデッドロックの発生を回避することができる。しかしながら、連動起動業務の開発者が、このＤＢの読み込み順序を守るよう意識するのは、負担が大きく、困難である。
【０２０７】
このため、第３実施形態では、派生ＤＢ制御処理として、派生インデックスＤＢの派生インデックスビットをＯＦＦにする処理を別トランザクションとしている。このため、派生特性管理共通処理では、派生インデックスＤＢの派生インデックスビットの更新を行わない。従って、１つのトランザクション内でＤＢｘのロックと派生インデックスＤＢのロックとを行うことがなくなる。派生ＤＢ制御処理は、派生ＤＢ（派生管理ＤＢと派生インデックスＤＢ）以外のＤＢを読み込まないため、デッドロックは生じない。
【０２０８】
再度図２５を参照して、本実施形態での派生トランザクション管理方法を説明する。派生トランザクション管理方法は、派生起動トランザクション（派生起動ＡＰＰＬ１１１Ａ）を実行すると共に、当該派生起動トランザクションによって起動要求依頼される派生トランザクション（派生受動ＡＰＰＬ１１３Ａ）のコミットを待機せずに当該派生起動トランザクションをコミットさせる派生起動トランザクション管理工程（１００Ａ，１１２Ａ）と、派生起動ＡＰＰＬ１１１Ａによって起動要求依頼された派生トランザクションを管理する派生トランザクション管理工程（派生特性管理共通処理１０４Ａ）と、この派生トランザクション管理工程にて派生トランザクションとして起動される派生ＤＢ管理工程（派生ＤＢ制御処理１１４Ａ）とを備えている。
【０２０９】
前記派生起動トランザクション管理工程は、当該派生起動トランザクションの一部として、当該派生起動トランザクションのＪＯＢ番号に応じて前記派生インデックスＤＢを参照し、前記派生管理ＤＢの派生管理通番を特定し、当該派生管理通番のセグメントに派生起動情報を格納し、当該使用した派生管理通番に対応する前記インデックスビット及び使用中フラグをそれぞれ使用中に更新して、当該派生トランザクションを起動させる派生要求共通処理工程（派生要求共通処理１１２Ａ）を備えている。
【０２１０】
そして、派生トランザクション管理工程は、前記派生トランザクションの一部として、派生要求共通処理工程１１２Ａにて派生トランザクションが起動されスケジュールされた場合に、当該派生トランザクションに与えられた派生管理通番をキー値として派生管理ＤＢを読み込み、当該派生管理通番の使用中フラグが使用中である場合には当該派生トランザクションのオペコードに応じた派生受動業務プログラムを実行させ、この派生受動業務プログラムが終了した後に前記派生管理ＤＢの使用中フラグをオフに更新して、さらに所定の派生ＤＢ制御処理を派生トランザクションとして起動させる派生特性管理共通処理工程（派生特性管理共通処理指令１０４Ａ）を備えている。この派生特性管理共通処理工程にて、インデックス・ビットマップの更新を行わないため、図２６に示すデッドロックが生じない。
【０２１１】
そして、派生ＤＢ管理工程は、前記派生ＤＢ制御処理がスケジュールされた場合に、前記派生受動業務プログラムを含む派生トランザクションを再起動するための派生起動情報が格納された派生管理ＤＢの派生管理通番に対応する前記派生インデックスＤＢの前記派生インデックスビットを使用可に更新する派生ＤＢ制御処理工程（派生ＤＢ制御処理指令１１４Ａ）を備える。派生ＤＢ制御処理工程では、１つのとして、インデックス・ビットマップの更新のみを行うため、他のトランザクションのロックの待機を行うことはあっても、デッドロックを生じることはない。また、派生ＤＢ制御処理による派生ＤＢ制御トランザクションは、図２５に示す例では、派生特性管理共通処理１０４Ａによって指定された派生管理通番にて派生管理ＤＢ７０を読み取るため、派生特性管理共通処理１０４Ａとの直列性を有する。すなわち、派生特性管理共通処理が正常にコミットした後に、インデックス・ビットマップを更新する。従って、並列処理によってシステム的な一貫性が失われることはない。
【０２１２】
また、図２４に示すように、第３実施形態においても総量制御部１４の各構成を備えるようにしても良い。第３実施形態では、システム負荷が大きい場合には、派生ＤＢ制御処理の起動を中止し、滞留の解消後に一括して派生インデックスビットをオフにする処理を行うようにしても良い。
【０２１３】
第３実施形態では、アボートされた派生トランザクションの再起動は、第２実施形態と同様である。業務メイン１００Ａ，派生起動ＡＰＰＬがアボートした場合には、使用中フラグ，派生インデックスビット共に使用可のままであり、派生トランザクションの起動要求もなされない。派生要求共通処理１１２Ａにて派生ＤＢ６８，７０の更新後、派生起動要求の出力前にアボートされた場合には、使用中フラグ及び派生インデックスビットは更新されるものの、ロールバックによってこの更新がなかったものとなる。そして、派生トランザクションもスケジュールされない。
【０２１４】
派生起動要求の出力後に派生要求共通処理１１２Ａや、業務メイン１００Ａや、派生起動ＡＰＰＬ１１１Ａが連動受動業務の場合で連動戻り後の連動起動業務の処理がアボートした場合にも、ロールバックによって派生要求共通処理のＤＢへの更新が無かったものとなる。しかし、派生メッセージはスケジュールされている可能性がある。この場合、派生特性管理共通処理１０４Ａ（３）にて使用中フラグをチェックする。使用中フラグを読み込めた時には派生起動トランザクションはアボートしている。このため、ロールバックによって更新されない状態の使用中フラグを読み取ることとなる。従って、派生特性管理共通処理１０４Ａ（３）では、使用中フラグが「使用可」であるため、派生受動ＡＰＰＬを呼び出さずに処理を終了する。この場合、派生起動トランザクションも派生トランザクションも無かったこととなる。
【０２１５】
派生起動トランザクションがコミットすると、使用中フラグが「使用中」の状態で派生管理ＤＢに耐久性を持って記録される。派生特性管理共通処理１０４Ａの（１）から（５）までと、派生受動ＡＰＰＬのアボートの場合、派生管理ＤＢの使用中フラグは使用中のままであり、派生インデックスＤＢも使用中のままである。派生受動ＡＰＰＬが完了後、派生特性管理共通処理が使用中フラグをオフにした後にアボートした場合や、さらに派生トランザクションを起動するための派生要求共通処理１１２Ａ等の処理中にアボートした場合には、ロールバックによって派生特性管理共通処理の更新が無かったものとなる。従って、使用中フラグは使用中（１）のままである。
【０２１６】
派生特性管理共通処理がコミットした後、派生ＤＢ制御処理がアボートしたとする。この場合、使用中フラグはオフとなっている。しかし、派生インデックスＤＢの派生インデックスビットはＯＮのままである。このように、（１）．派生起動トランザクションのアボートの場合には、派生トランザクションは起動しない。（２）．派生トランザクションがコミットしたが、派生受動ＡＰＰＬ１１３Ａや派生特性管理共通処理１０４Ａがアボートした場合には、使用中フラグ及び派生インデックスビットが共に使用中のままである。（３）．派生トランザクションもコミットしたが、派生ＤＢ制御処理１１４Ａがアボートした場合には、使用中フラグが使用可で、派生インデックスビットがＯＮの状態である。
【０２１７】
派生トランザクションの再起動が必要となるのは、（２）．の場合である。従って、使用中フラグがＯＮで、起動と一定時間が経過している処理を探索することで、再起動の要否を判定すべき派生トランザクションを特定することができる。（３）．の派生ＤＢ制御処理１１４Ａのアボートの場合には、派生受動ＡＰＰＬ及び派生特性管理共通処理１０４Ａは正常にコミットしているため、派生トランザクションを再起動する必要はない。
【０２１８】
上述したように本実施形態によると、派生と連動とが複雑に絡み合った状態で生じるデッドロックを派生ＤＢ制御処理によって回避することができるため、開発者がプログラム作成上の調整を行う必要がなくなる。
【０２１９】
【発明の効果】
本発明は、その構成によって、オンライン応答が必要なオンライントランザクションと、オンライントランザクション等に付随した処理を実行する派生トランザクションとに区分けされて実行される。このため、オンライン応答に必要な処理をオンライントランザクションとして処理し、オンライン応答に必要のない付随処理を派生トランザクションとしてオンライントランザクションのコミット後に処理する。従って、オンライントランザクションを早期にコミットさせることができる。これにより、オンラインの応答性を確保しつつ、付随的な業務のみを事後的に派生トランザクションとして処理することができる。従って、従来バッチ処理で行っていたような処理について派生トランザクションを利用してオンライントランザクションと並行した処理が可能となる。このように、本発明によると、派生トランザクションモデルを用いることで、従来バッチ処理等で実現していた処理や、１つのトランザクションとしては処理量が多くなる処理を実行しつつ、オンラインの応答性を確保することができる、というトランザクション制御システムを実現することができる。
【図面の簡単な説明】
【図１】図１は本実施形態によるオンライントランザクション制御システムの構成を示すブロック図である。
【図２】図２は、派生トランザクションの性質を説明する説明図であり、図２（Ａ）は、派生起動トランザクションから派生トランザクションの起動要求がなされる例を示す図で、図２（Ｂ）は、派生起動トランザクションが連動トランザクションである場合を示す図で、図２（Ｃ）は、派生トランザクションが自らを派生トランザクションとして起動要求する例を示す図である。
【図３】図３は派生トランザクションの利用法に応じた端末応答等を説明するための説明図であり、図３（Ａ）は、付随業務の場合を示す図で、図３（Ｂ）は取消再カットメインの場合を示す図である。
【図４】図４は、取消再カットメインの動作例を示す説明図である。
【図５】図５は端末折り返し連続処理に派生トランザクションを用いた例を示す説明図である。
【図６】図６は、トランザクションの総量制御の一例を示すフローチャートである。
【図７】図７は、第２実施形態の構成を示すブロック図である。
【図８】図８は、ＪＯＢと派生インデックスＤＢ等との関係を示す説明図である。
【図９】図９は、派生ＤＢのデータ項目を例示する説明図であり、図９（Ａ）は派生インデックスＤＢの項目例を示す図で、図９（Ｂ）は派生管理ＤＢの項目例を示す図である。
【図１０】図１０は、ＪＯＢ ＩＤと、派生インデックスＤＢのインデックス領域番号と、ビット位置と、派生管理通番との関係を例示する説明図であり、図１０（Ａ）はＪＯＢ ＩＤ０００で実行されているトランザクションによって読み出される派生インデックスＤＢとそのビット位置及び派生管理通番の関係を示す図で、図１０（Ｂ）はこの場合の派生管理ＤＢの内容の例を示す図で、図１０（Ｃ）はＪＯＢ ＩＤ００１で実行されているトランザクションによって読み出される派生インデックスＤＢとそのビット位置及び派生管理通番の関係を示す図で、図１０（Ｄ）はこの場合の派生管理ＤＢの内容例を示す図である。
【図１１】図１１は、派生トランザクションの要求を管理するための派生要求管理処理の一例を示すフローチャートである。
【図１２】図１２は、派生トランザクションの特性を管理するための派生特性管理処理の一例を示すフローチャートである。
【図１３】図１３は、オペコードテーブルの一例を示す図で、ここでは普通預金のオペコードテーブルを例示する。
【図１４】図１４は、取消再カットメインでの処理例を示す説明図であり、図１４（Ａ）は口座処理による電気料引落（内部自振）の取消を行う例を示す図で、図１４（Ｂ）はその処理による残高の推移を示す図である。
【図１５】図１５は、図１４に示した処理でのＦＩＦＯ推移及び派生メッセージの例を示す説明図である。
【図１６】図１６は、図１５に続くＦＩＦＯ等の推移を示す説明図である。
【図１７】図１７は、図１４及び図１５に示す例での派生ＤＢの利用例を示す説明図である。
【図１８】図１８は、ＪＯＢを一般トランザクションと派生トランザクションとに別々に割り当てる例を示す説明図である。
【図１９】図１９は、滞留監視処理の一例を示すフローチャートである。
【図２０】図２０は、派生トランザクションの実行を待機させる総量制御処理の例を示す図表である。
【図２１】図２１は、アボートされた派生トランザクションの再起動処理の一例を示すブロック図である。
【図２２】図２２は、派生トランザクションの再起動の要否を判定する処理の一例を示すフローチャートである。
【図２３】図２３は、派生トランザクションの再起動処理の一例を示すフローチャートである。
【図２４】図２４は、第３実施形態の構成を示すブロック図である、
【図２５】図２５は、派生管理処理の構成を示す説明図である。
【図２６】図２６は、派生ＤＢ制御処理を別トランザクションとしない場合に生じる可能性のあるデッドロックの態様の一例を示す説明図である。
【符号の説明】
２ 受信手段
４ 演算手段
６ ファイル
８ メッセージ入力手段
１０ オンライン応答部
１２ 派生トランザクション管理部
１４ 総量制御部
１６ トランザクション実行部
Claims (19)
- 端末からネットワークを介して入力される業務処理要求を受信する受信手段と、この受信手段にて受信した業務処理要求を処理する演算手段と、この演算手段の処理結果を記録するファイルとを備え、
前記演算手段は、
所定のオンライントランザクション及び所定の派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルのデータ項目をロックし、処理し、前記ファイルに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理する派生トランザクション管理部とを備えたトランザクション制御システムにおいて、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記派生トランザクション管理部は、
前記派生トランザクションの起動と開始とを管理し、
前記起動要求依頼が出力された際に、当該派生トランザクションの起動処理とは別に、当該派生トランザクションの起動要求依頼に関連する派生起動情報を前記ファイルに記録し、当該派生起動情報の記録を、前記派生起動トランザクションの原子性に包む制御をすることで、派生トランザクションの起動を管理する派生起動情報格納制御機能と、
当該起動要求依頼された派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせる機能と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、当該起動要求依頼された派生トランザクションの処理を開始させることで、前記派生トランザクションの開始を管理する直列性管理機能とを備えたことを特徴とするトランザクション制御システム。 - 前記派生トランザクション管理部は、前記派生起動トランザクションがコミットした後に前記派生トランザクションがアボートした場合には前記派生起動情報に基づいて当該派生トランザクションを再起動させる派生再起動制御機能とを備えたことを特徴とする請求項１記載のトランザクション制御システム。
- 前記演算手段は、前記オンライン応答部及び派生トランザクション管理部によって実行が管理される各トランザクションの総量に応じて前記派生トランザクションの開始を制限させる総量制御部を備え、
前記総量制御部は、実行を待機しているトランザクションの総数を監視する実行状況監視機能と、
この実行状況監視機能によって実行待機中のトランザクション数が予め定められた数を超えたと判定された場合には、前記派生起動情報が前記ファイルに記録された状態で派生トランザクションの開始を中止する派生起動中止制御機能を備えたことを特徴とする請求項１又は２記載のトランザクション制御システム。 - 前記トランザクション実行部は、
前記派生起動トランザクションの実行によって業務上の一貫性に関して中間的なデータが生じる場合には当該中間的なデータについて耐久性を持った状態で前記ファイルに記録し、
この業務処理要求の実行によって生じた業務上の一貫性に関する中間的な状態を解消して業務上の一貫性を保つための判定及び実行を前記派生トランザクションとして実行することを特徴とする請求項１，２又は３記載のオンラインシステム。 - 端末からネットワークを介して入力される業務処理要求を受信する受信手段と、この受信手段にて受信した業務処理要求を処理する演算手段と、この演算手段の処理結果を記録するファイルとを備え、
この演算手段は、
所定のオンライントランザクション及び所定の派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルのデータ項目をロックし、処理し、前記ファイルに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理する派生トランザクション管理部とを備えたトランザクション制御システムの前記派生トランザクション管理部を使用して、
前記各トランザクションを管理するトランザクション制御方法であって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記起動要求依頼が出力された際に、当該派生トランザクションの起動処理とは別に、当該派生トランザクションの起動要求依頼に関連する派生起動情報を前記ファイルに記録し、当該派生起動情報の記録を、前記派生起動トランザクションの原子性に包む制御をすることで、派生トランザクションの起動を管理する工程と、
前記派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせる工程と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、当該起動要求依頼された派生トランザクションの処理を開始させることで、前記派生トランザクションの開始を管理する工程とを備えたことを特徴とするトランザクション制御方法。 - 端末からネットワークを介して入力される業務処理要求を受信する受信手段と、この受信手段にて受信した業務処理要求を処理する演算手段と、この演算手段の処理結果を記録するファイルとを備え、
この演算手段は、
所定のオンライントランザクション及び所定の派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルのデータ項目をロックし、処理し、前記ファイルに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理する派生トランザクション管理部とを備えたトランザクション制御システムの前記派生トランザクション管理部に所定の工程を実現させるためのトランザク ション制御プログラムであって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記派生起動トランザクションから派生トランザクションの起動要求依頼が出力された際の処理の工程として、前記派生トランザクション管理部に対して、
前記起動要求依頼が出力された際に、当該派生トランザクションの起動処理とは別に、当該派生トランザクションの起動要求依頼に関連する派生起動情報を前記ファイルに記録し、当該派生起動情報の記録を、前記派生起動トランザクションの原子性に包む制御をすることで、派生トランザクションの起動を管理する工程と、
前記派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせる工程と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、当該起動要求依頼された派生トランザクションの処理を開始させることで、前記派生トランザクションの開始を管理する工程とを実現させることを特徴とするトランザクション制御プログラム。 - 端末からネットワークを介して入力される業務処理要求を受信する受信手段と、この受信手段にて受信した業務処理要求を処理する演算手段と、この演算手段の処理結果を記録するファイルとを備え、
前記ファイルが、前記業務処理要求に関連した各種マスタＤＢと、所定の派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録する派生管理ＤＢと、この派生管理ＤＢのキーとなる派生管理通番毎に派生管理ＤＢが使用中であるか否かを指示するインデックス情報を記録する派生インデックスＤＢとを備え、
前記演算手段が、
所定のオンライントランザクション及び前記派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理するトランザクション管理部とを備え、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記トランザクション管理部が、前記派生起動トランザクションから新たな派生トランザクションの起動要求依頼が出力された際には、前記派生インデックスＤＢのインデックス情報を特定すると共に当該特定したインデックス情報に基づいて前記派生管理ＤＢの使用可な派生管理通番を特定する派生管理通番特定機能と、
この派生管理通番特定機能によって特定された派生管理通番のセグメントに、当該派生トランザクションの起動処理とは別に、当該起動要求された派生トランザクションの派生起動情報を記録し、当該派生起動情報の記録を前記派生起動トランザクションの原子性に 包む制御をし、当該派生起動情報の記録後に、当該派生トランザクションを起動させる派生起動情報格納制御機能と、
当該派生起動トランザクションの各処理が正常終了した際に、当該起動要求依頼された派生トランザクションの開始を待機せずに、当該派生起動トランザクションをコミットさせる派生起動トランザクションコミット処理機能と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、前記起動された派生トランザクションが当該派生管理通番の前記派生起動情報をロック可能な状態での正常な読み出しに成功した後に、当該派生トランザクションの各処理を開始させる直列性制御機能と、
前記派生トランザクションの各処理が正常終了した際に、当該派生管理通番の前記派生インデックスＤＢ及び前記派生管理ＤＢを使用可に更新させると共に当該派生トランザクションをコミットさせる派生トランザクションコミット処理機能と、
前記派生トランザクションがアボートされた際に、前記派生管理ＤＢに格納した派生起動情報に基づいた再起動を制御する派生再起動制御機能とを備えたことを特徴とするトランザクション制御システム。 - 前記派生起動トランザクションが、予め定められたＪＯＢ番号群の中のいずれかのＪＯＢ番号で実行され、
前記派生インデックスＤＢが、前記派生起動トランザクションのＪＯＢ番号をキー値とするインデックス領域番号毎に前記インデックス情報を有することを特徴とした請求項７記載のトランザクション制御システム。 - 前記派生インデックスＤＢが、前記インデックス情報を前記インデックス領域番号毎のビットマップとして保有し、
前記派生管理通番特定機能が、前記インデックス領域番号と前記ビットマップのビット位置とに基づいて前記派生管理ＤＢの派生管理通番を特定する機能を備えたことを特徴とする請求項８記載のトランザクション制御システム。 - 前記派生インデックスＤＢが、前記インデックス領域番号毎のビットマップを派生インデックスビットとして有すると共に、当該派生インデックスビットのＯＮ又はＯＦＦに応じて当該ビットのビット位置に対応する派生管理ＤＢの使用状態を記録し、
前記派生管理ＤＢが、前記派生管理通番毎に当該派生管理通番の使用状態を使用中又は使用可として記録する使用中フラグを有し、
前記派生管理通番特定機能が、ＯＦＦとなっている派生インデックスビット及び当該使用可となっている派生管理通番を特定したときに当該派生インデックスビットについて使用中を示すＯＮへと更新し、
前記派生起動情報格納制御機能が、前記派生起動情報を格納したときに当該派生管理通番の使用中フラグを「使用中」へと更新し、
前記直列性制御機能は、前記派生起動トランザクションから渡された派生管理通番の使用中フラグが使用可であった場合には、当該派生トランザクションがアボートしたとして、当該起動要求されている派生トランザクションを開始せずにアボートさせ、
派生トランザクションコミット制御機能は、当該派生トランザクションの完了時又は完了後に前記派生インデックスビット及び前記使用中フラグについて使用可へと更新することを特徴とする請求項９記載のトランザクション制御システム。 - 前記演算手段が、前記オンライントランザクション及び前記派生トランザクションを予め定められた数の前記ＪＯＢ番号を単位に並列して処理し、この演算手段の前記ＪＯＢ番号へとスケジュールされる各トランザクションの要求を一時的に格納する待ち行列を備え、この待ち行列が、前記オンライントランザクションの要求を一時的に格納する一般待ち行列と、前記派生トランザクションの要求を一時的に格納する派生待ち行列とを有し、
前記演算手段が、前記一般待ち行列及び派生待ち行列で滞留しているトランザクション数を監視する滞留監視部と、この滞留監視部によって監視される各待ち行列でのトランザクションの滞留数に応じて前記派生起動トランザクション又は前記派生トランザクションの起動を制御する総量制御部とを備え、
前記滞留監視部は、前記一般待ち行列又は派生待ち行列の滞留数が予め定められたレベル以上である場合には派生中止ビットをＯＮとし、
前記総量制御部は、前記派生中止ビットがＯＮである場合には派生起動要求があった時には当該派生起動情報を前記派生管理ＤＢに記録後、派生トランザクションの開始を行わない派生起動中止制御機能とを備えたことを特徴とする請求項８記載のトランザクション制御システム。 - 前記派生起動情報格納制御機能が、前記派生管理通番特定機能によって特定された派生管理通番のセグメントに前記派生起動トランザクションによる派生トランザクションの起動要求依頼に関する情報及び起動時刻を派生起動情報として格納し、
前記演算手段は、前記派生インデックスＤＢ及び前記派生管理ＤＢを参照して、前記インデックス情報が使用中を示し、かつ、前記起動時刻を参照して、派生管理ＤＢに派生起動情報を格納した後予め定められた時間以上経過している派生管理通番を派生再起動要と判定する派生再起動要否監視部を備えたことを特徴とする請求項７又は８記載のトランザクション制御システム。 - 前記演算手段は、前記派生再起動要否監視部によって再起動要と判定された派生管理通番を再起動する場合には、当該派生管理通番によって特定される派生起動情報に基づいて派生トランザクションを起動すると共に当該派生管理通番へ派生起動情報を格納した時刻を更新する派生再起動制御部とを備えたことを特徴とする請求項７又は１２記載のトランザクション制御システム。
- 端末からネットワークを介して入力される業務処理要求を受信する受信手段と、この受信手段にて受信した業務処理要求を処理する演算手段と、この演算手段の処理結果を記録するファイルとを備え、
前記ファイルが、前記業務処理要求に関連した各種マスタＤＢと、所定の派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録する派生管理ＤＢと、この派生管理ＤＢのキーとなる派生管理通番毎に派生管理ＤＢが使用中であるか否かを指示するインデックス情報を記録する派生インデックスＤＢとを備え、
前記演算手段が、
所定のオンライントランザクション及び前記派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理するトランザクション管理部とを備えたトランザクション制御システムの前記トランザクション管理部を使用して、
前記各トランザクションを管理するトランザクション制御方法であって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記派生起動トランザクションから新たな派生トランザクションの起動要求依頼が出力された際には、前記派生インデックスＤＢのインデックス情報を特定すると共に当該特定したインデックス情報に基づいて前記派生管理ＤＢの使用可となっている派生管理通番を特定する派生管理通番特定工程と、
この派生管理通番特定工程にて特定された派生管理通番のセグメントに、当該派生トランザクションの起動処理とは別に、当該起動要求依頼された派生起動トランザクションの派生起動情報を記録し、当該派生起動情報の記録を前記派生起動トランザクションの原子性に包む制御をし、当該派生起動情報の記録後に、当該派生トランザクションを起動させる派生起動情報格納制御工程と、
当該派生起動トランザクションの各処理が正常終了した際に、当該起動要求依頼された派生トランザクションの開始を待機せずに、当該派生起動トランザクションをコミットさせる派生起動トランザクションコミット処理工程と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、前記派生トランザクションが当該派生管理通番の前記派生起動情報をロック可能な状態での正常な読み出しに成功した後に、当該派生トランザクションの各処理を開始させる直列性制御工程と、
前記派生トランザクションの各処理が正常終了した際に、当該派生管理通番の前記派生インデックスＤＢ及び前記派生管理ＤＢを使用可に更新させると共に当該派生トランザクションをコミットさせる派生トランザクションコミット処理工程と、
前記派生トランザクションがアボートされた際に、前記派生管理ＤＢに格納した派生起動情報に基づいた再起動を制御する派生再起動制御工程とを備えたことを特徴とするトランザクション制御方法。 - 端末からネットワークを介して入力される業務処理要求を受信する受信手段と、この受信手段にて受信した業務処理要求を処理する演算手段と、この演算手段の処理結果を記録するファイルとを備え、
前記ファイルが、前記業務処理要求に関連した各種マスタＤＢと、所定の派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録する派生管理ＤＢと、この派生管理ＤＢのキーとなる派生管理通番毎に派生管理ＤＢが使用中であるか否かを指示するインデックス情報を記録する派生インデックスＤＢとを備え、
前記演算手段が、
所定のオンライントランザクション及び前記派生トランザクションを並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除するトランザクション実行部と、
前記端末から入力される業務処理要求をオンライントランザクションとして前記トランザクション実行部に処理させ、当該オンライントランザクションの処理結果を前記端末への応答として出力する制御をするオンライン応答部と、
前記派生トランザクションを前記トランザクション実行部に処理させ、各トランザクションのコミットを管理するトランザクション管理部とを備えたトランザクション制御システムの前記トランザクション管理部に所定の工程を実現させるためのトランザクション制御プログラムであって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記派生起動トランザクションから派生トランザクションの起動要求依頼が出力された際の処理の工程として、前記派生トランザクション管理部に対して、
前記オンライントランザクション又は派生トランザクションである派生起動トランザクションから新たな派生トランザクションの起動要求依頼が出力された際には、前記派生インデックスＤＢのインデックス情報を特定すると共に当該特定したインデックス情報に基づいて前記派生管理ＤＢの使用可となっている派生管理通番を特定する派生管理通番特定工程と、
この派生管理通番特定工程にて特定された派生管理通番のセグメントに、当該派生トランザクションの起動処理とは別に、当該起動要求依頼された派生起動トランザクションの派生起動情報を記録し、当該派生起動情報の記録を前記派生起動トランザクションの原子性に包む制御をし、当該派生起動情報の記録後に、当該派生トランザクションを起動させる派生起動情報格納制御工程と、
当該派生起動トランザクションの各処理が正常終了した際に、当該起動要求依頼された派生トランザクションの開始を待機せずに、当該派生起動トランザクションをコミットさせる派生起動トランザクションコミット処理工程と、
前記派生起動トランザクションがコミットした際に、当該派生起動トランザクションによる前記ロックを解除することで他のオンライントランザクションによる当該ロック解除されたデータ項目へのアクセスを許容しつつ、前記派生トランザクションが当該派生管理通番の前記派生起動情報をロック可能な状態での正常な読み出しに成功した後に、当該派生トランザクションの各処理を開始させる直列性制御工程と、
前記派生トランザクションの各処理が正常終了した際に、当該派生管理通番の前記派生インデックスＤＢ及び前記派生管理ＤＢを使用可に更新させると共に当該派生トランザクションをコミットさせる派生トランザクションコミット処理工程と、
前記派生トランザクションがアボートされた際に、前記派生管理ＤＢに格納した派生起動情報に基づいた再起動を制御する派生再起動制御工程とを実現させることを特徴とするトランザクション制御プログラム。 - 端末からネットワークを介して入力される業務処理要求を受信する受信手段と、この受信手段にて受信した業務処理要求に応じたオンライントランザクション及び所定の派生トランザクションを予め定められた数のＪＯＢ番号を単位に並列して処理する演算手段と、この演算手段の処理結果を記録するファイルとを備え、
前記ファイルが、
前記業務処理要求に関連した各種マスタＤＢと、
前記派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録すると共に当該派生管理通番が使用中であるか又は使用可であるかを示す使用中フラグを有する派生管理ＤＢと、
この派生管理ＤＢでの派生管理通番を前記各トランザクションのＪＯＢ番号を単位とした複数の派生管理通番から使用可の派生管理通番を特定すると共に前記派生管理通番が使用中であるか否かをビットのＯＮ又はＯＦＦにて示す派生インデックスビットを前記ＪＯＢ番号毎に複数有する派生インデックスＤＢとを備え、
前記演算手段が、
前記オンライントランザクション及び派生トランザクションを構成するプログラムの実行を管理する業務メイン処理部と、
この業務メイン処理部によって実行が管理されるプログラムを前記ＪＯＢ番号毎のトランザクションの一部として並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除する業務処理部とを備え、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
前記業務処理部は、前記端末から入力される業務処理要求をオンライントランザクションとして処理し、当該オンライントランザクションの処理結果を前記端末への応答として出力し、
前記業務メイン処理部は、前記派生トランザクションの起動を管理する派生要求共通処理と、前記派生トランザクションの開始及び完了を管理する派生特性管理共通処理と、前記派生トランザクションの完了の一部を管理する派生ＤＢ制御処理とを実行し、
前記派生要求共通処理は、前記派生起動トランザクションの原子性に包まれる処理として、前記プログラムの実行中に新たな派生トランザクションの派生起動要求依頼が出力された際に、当該派生起動トランザクションのＪＯＢ番号に応じて前記派生インデックスＤＢを参照し、前記派生管理ＤＢの派生管理通番を特定し、当該派生トランザクションの起動処理とは別に、当該派生管理通番のセグメントに当該派生起動情報を格納し、当該派生管理通番に対応する前記インデックスビット及び使用中フラグをそれぞれ使用中の状態に更新して、当該派生トランザクションを起動させることで、当該派生トランザクションの起動を管理し、業務メイン処理部は、当該起動後で当該派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせることで当該派生起動トランザクションのロックを解除し、当該ロック解除したデータ項目への他のトランザクションによるアクセスを許容し、
前記派生特性管理共通処理は、当該起動された派生トランザクションの原子性に包まれる処理として、当該派生トランザクションが起動され、当該派生トランザクションに与えられた派生管理通番をキー値とする派生管理ＤＢの読み込みに成功した際に、当該派生管理通番の使用中フラグが使用中である場合には、当該派生トランザクションの処理を実行させ、一方、当該使用中フラグが使用可である場合には、当該派生トランザクションをアボートすることで、当該派生トランザクションの開始を管理し、前記業務処理部は、当該派生トランザクションの処理を実行し、
当該派生特性管理処理は、当該派生トランザクションの原子性に包まれる処理として、当該派生トランザクションの処理が終了した後に、前記派生管理ＤＢの使用中フラグを使用可に更新して、前記派生ＤＢ制御処理を当該起動要求依頼された派生トランザクションとは別の派生トランザクションとして起動させ、この起動後に、当該派生トランザクションをコミットし、
前記派生ＤＢ制御処理は、前記派生ＤＢ制御処理がスケジュールされた場合に、当該派生管理通番に対応する前記派生インデックスＤＢの前記派生インデックスビットを使用可を示すＯＦＦへ更新することを特徴とするトランザクション制御システム。 - 前記派生インデックスＤＢが、前記派生インデックスビットを前記ＪＯＢ番号を単位としたビットマップとして保有すると共に当該ビットマップのビット位置で前記派生管理通番を特定し、
前記派生ＤＢ制御処理機能が、前記派生管理通番から前記ビットマップ及びビット位置を算出することを特徴とする請求項１６記載のトランザクション制御システム。 - 端末からネットワークを介して入力される業務処理要求を受信する受信手段と、この受信手段にて受信した業務処理要求に応じたオンライントランザクション及び所定の派生トランザクションを予め定められた数のＪＯＢ番号を単位に並列して処理する演算手段と、この演算手段の処理結果を記録するファイルとを備え、
前記ファイルが、
前記業務処理要求に関連した各種マスタＤＢと、
前記派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録すると共に当該派生管理通番が使用中であるか又は使用可であるか示す使用中フラグを有する派生管理ＤＢと、
この派生管理ＤＢでの派生管理通番を前記各トランザクションのＪＯＢ番号を単位とした複数の派生管理通番から使用可の派生管理通番を特定すると共に前記派生管理通番が使用中であるか否かを示す派生インデックスビットを前記ＪＯＢ番号毎に複数有する派生インデックスＤＢとを備え、
前記演算手段が、
前記オンライントランザクション及び派生トランザクションを構成するプログラムの実行を管理する業務メイン処理部と、
この業務メイン処理部によって実行が管理されるプログラムを前記ＪＯＢ番号毎のトランザクションの一部として並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除する業務処理部とを備えたオンラインシステムの前記演算手段を使用してトランザクションを管理するトランザクション制御方法であって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
派生起動トランザクションの起動を管理すると共に当該派生起動トランザクションによって起動要求依頼される派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせることで当該派生起動トランザクションのロックを解除し、当該ロック解除したデータ項目への他のトランザクションによるアクセスを許容する派生起動トランザクション管理工程と、
前記派生起動トランザクションによって起動要求依頼された派生トランザクションの開始及び管理を管理する派生トランザクション管理工程と、
この派生トランザクション管理工程にて派生トランザクションとして起動される派生ＤＢ管理工程とを備え、
前記派生起動トランザクション管理工程は、当該派生起動トランザクションの原子性に包まれる処理として、当該派生起動トランザクションのＪＯＢ番号に応じて前記派生インデックスＤＢを参照し、前記派生管理ＤＢの派生管理通番を特定し、当該派生トランザクションの起動処理とは別に、当該派生管理通番のセグメントに派生起動情報を格納し、当該使用した派生管理通番に対応する前記インデックスビット及び使用中フラグをそれぞれ使用中の状態に更新して、当該派生トランザクションを起動させることで、当該派生トランザクションの起動を管理する派生要求共通処理工程を備え、
前記派生トランザクション管理工程は、当該起動された派生トランザクションの原子性に包まれる処理として、当該派生トランザクションが起動されスケジュールされ、当該派生トランザクションに与えられた派生管理通番をキー値とする派生管理ＤＢの読み込みに成功した際に、当該派生管理通番の使用中フラグが使用中である場合には当該派生トランザクションの処理を実行させ、一方、当該使用中フラグが使用可である場合には、当該派生トランザクションをアボートすることで、当該派生トランザクションの開始を管理し、
当該派生トランザクションの処理が終了した後に、前記派生管理ＤＢの使用中フラグを使用可に更新して、さらに所定の派生ＤＢ制御処理を派生トランザクションとして起動させ、この起動後に、当該派生トランザクションをコミットする派生特性管理共通処理工程を備え、
前記派生ＤＢ管理工程は、前記派生ＤＢ制御処理がスケジュールされた場合に、当該派生管理通番に対応する前記派生インデックスＤＢの前記派生インデックスビットを使用可を示すＯＦＦに更新する派生ＤＢ制御処理工程を備えたことを特徴とするトランザクション制御方法。 - 端末からネットワークを介して入力される業務処理要求を受信する受信手段と、この受信手段にて受信した業務処理要求に応じたオンライントランザクション及び所定の派生トランザクションを予め定められた数のＪＯＢ番号を単位に並列して処理する演算手段と、この演算手段の処理結果を記録するファイルとを備え、
前記ファイルが、
前記業務処理要求に関連した各種マスタＤＢと、
前記派生トランザクションの起動要求依頼に関連する派生起動情報を派生管理通番毎に記録すると共に当該派生管理通番が使用中であるか又は使用可であるか示す使用中フラグを有する派生管理ＤＢと、
この派生管理ＤＢでの派生管理通番を前記各トランザクションのＪＯＢ番号を単位とした複数の派生管理通番から使用可の派生管理通番を特定すると共に前記派生管理通番が使用中であるか否かを示す派生インデックスビットを前記ＪＯＢ番号毎に複数有する派生インデックスＤＢとを備え、
前記演算手段が、
前記オンライントランザクション及び派生トランザクションを構成するプログラムの実行を管理する業務メイン処理部と、
この業務メイン処理部によって実行が管理されるプログラムを前記ＪＯＢ番号毎のトランザクションの一部として並列に実行し、この各トランザクションの実行に際して、それぞれ、前記ファイルの前記各ＤＢのデータ項目をロックし、処理し、前記ファイルの各ＤＢに当該処理結果を記録し、当該記録後に前記ロックを解除する業務処理部とを備え、
前記演算手段に所定の工程を実現させるためのトランザクション制御プログラムであって、
前記各トランザクションの実行中に、新たなトランザクションの起動要求依頼を出力するトランザクションを派生起動トランザクションとし、当該起動要求依頼されたトランザクションを派生トランザクションとして、
前記派生トランザクションは、前記オンライントランザクションの前記処理結果に付随して生じ、かつ、前記オンライントランザクションの応答には必要ない付随業務の全部又は一部を処理するトランザクションであって、
派生起動トランザクションの起動を管理すると共に当該派生起動トランザクションによって起動要求依頼される派生トランザクションの開始を待機せずに当該派生起動トランザクションをコミットさせることで当該派生起動トランザクションのロックを解除し、当該ロック解除したデータ項目への他のトランザクションによるアクセスを許容する派生起動トランザクション管理工程と、
前記派生起動トランザクションによって起動要求依頼された派生トランザクションの開始及び管理を管理する派生トランザクション管理工程と、
この派生トランザクション管理工程にて起動要求依頼された派生トランザクションとは別の派生トランザクションとして起動される派生ＤＢ管理工程とを前記演算手段に実現させ、
前記派生起動トランザクション管理工程の一部として、当該派生起動トランザクションの原子性に包まれる処理として、当該派生起動トランザクションのＪＯＢ番号に応じて前記派生インデックスＤＢを参照し、前記派生管理ＤＢの派生管理通番を特定し、当該派生トランザクションの起動処理とは別に、当該派生管理通番のセグメントに派生起動情報を格納し、当該使用した派生管理通番に対応する前記インデックスビット及び使用中フラグをそれぞれ使用中の状態に更新して、当該派生トランザクションを起動させることで、当該派生トランザクションの起動を管理する派生要求共通処理工程を実現させ、
前記派生トランザクション管理工程の一部として、当該起動された派生トランザクションの原子性に包まれる処理として、当該派生トランザクションが起動されスケジュールされ、当該派生トランザクションに与えられた派生管理通番をキー値とする派生管理ＤＢの読み込みに成功した際に、当該派生管理通番の使用中フラグが使用中である場合には当該派生トランザクションの処理を実行させ、一方、当該使用中フラグが使用可である場合には、当該派生トランザクションをアボートすることで、当該派生トランザクションの開始を管理し、
当該派生トランザクションの処理が終了した後に、前記派生管理ＤＢの使用中フラグを使用可に更新して、さらに所定の派生ＤＢ制御処理を派生トランザクションとして起動させ、この起動後に、当該派生トランザクションをコミットする派生特性管理共通処理工程を実現させ、
前記派生ＤＢ管理工程の一部として、前記派生ＤＢ制御処理がスケジュールされた場合に、当該派生管理通番に対応する前記派生インデックスＤＢの前記派生インデックスビットを使用可を示すＯＦＦに更新する派生ＤＢ制御処理工程を実現させることを特徴とするトランザクション制御プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001143203A JP3732113B2 (ja) | 2001-05-14 | 2001-05-14 | トランザクション制御システム、方法及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001143203A JP3732113B2 (ja) | 2001-05-14 | 2001-05-14 | トランザクション制御システム、方法及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002342138A JP2002342138A (ja) | 2002-11-29 |
| JP3732113B2 true JP3732113B2 (ja) | 2006-01-05 |
Family
ID=18989382
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001143203A Expired - Lifetime JP3732113B2 (ja) | 2001-05-14 | 2001-05-14 | トランザクション制御システム、方法及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3732113B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010134437A1 (ja) | 2009-05-18 | 2010-11-25 | Nishiyama Shuhei | 仮想単一メモリストレージ上におけるメタ情報共有型分散データベース・システム |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4555624B2 (ja) * | 2004-07-29 | 2010-10-06 | 新日鉄ソリューションズ株式会社 | データ処理システム、データ処理方法及びそのプログラム |
| JP5011728B2 (ja) * | 2006-01-11 | 2012-08-29 | 日本電気株式会社 | ホットスタンバイ方式を採用したシステム及びそれに用いる同期方法 |
| JP2008097476A (ja) * | 2006-10-16 | 2008-04-24 | Hitachi Ltd | 逐次処理方式のバッチシステム |
| US7899999B2 (en) * | 2007-06-27 | 2011-03-01 | Microsoft Corporation | Handling falsely doomed parents of nested transactions |
| JP2009020765A (ja) * | 2007-07-12 | 2009-01-29 | Hitachi Computer Peripherals Co Ltd | リードライト方法及び該リードライト方法を使用したコンピュータシステム |
| US7890472B2 (en) | 2007-09-18 | 2011-02-15 | Microsoft Corporation | Parallel nested transactions in transactional memory |
| JP5086934B2 (ja) * | 2008-08-07 | 2012-11-28 | 株式会社三菱東京Ｕｆｊ銀行 | データ処理装置及びプログラム |
| JP4462504B1 (ja) * | 2009-09-23 | 2010-05-12 | 修平 西山 | 一貫性保持の起点となるトランザクション・プロセスが所有する更新アクセス・カウンタによるマルチ・トランザクション制御システム |
| JP5295395B2 (ja) * | 2012-01-04 | 2013-09-18 | 株式会社三菱東京Ｕｆｊ銀行 | データ処理装置 |
| JP5604554B2 (ja) * | 2013-04-30 | 2014-10-08 | 株式会社三菱東京Ｕｆｊ銀行 | データ処理装置 |
| JP7784288B2 (ja) * | 2021-12-15 | 2025-12-11 | 株式会社Ｎｔｔデータ | 情報処理装置、情報処理方法及びプログラム |
| CN116993505B (zh) * | 2023-09-25 | 2024-01-16 | 腾讯科技（深圳）有限公司 | 交易处理方法、装置、电子设备及存储介质 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH02118841A (ja) * | 1988-10-28 | 1990-05-07 | Nec Corp | 入力待ち行列管理方式 |
| JPH0792788B2 (ja) * | 1989-02-14 | 1995-10-09 | 日本電気株式会社 | トランザクションメッセージ出力制御方式 |
| JP2817773B2 (ja) * | 1995-02-06 | 1998-10-30 | 日本電気株式会社 | トランザクションを跨がったプログラムループの検出方式 |
| JP3672208B2 (ja) * | 1996-07-02 | 2005-07-20 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 階層化トランザクション処理方法 |
| US7184988B1 (en) * | 1999-01-28 | 2007-02-27 | Certco, Inc. | Methods for operating infrastructure and applications for cryptographically-supported services |
| JP3471728B2 (ja) * | 2000-08-10 | 2003-12-02 | 株式会社八十二銀行 | 先日付完結処理システム及び方法 |
| JP3611110B2 (ja) * | 2001-03-19 | 2005-01-19 | 株式会社八十二銀行 | 先日付完結処理のシステム、方法、プログラム及びこれに用いる取消再カットメイン処理用プログラム並びに資源利用最適化システム、プログラム及びこれに用いる取消再実行メイン処理用プログラム |
-
2001
- 2001-05-14 JP JP2001143203A patent/JP3732113B2/ja not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010134437A1 (ja) | 2009-05-18 | 2010-11-25 | Nishiyama Shuhei | 仮想単一メモリストレージ上におけるメタ情報共有型分散データベース・システム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002342138A (ja) | 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 (zh) | 用于直接更新软件事务存储器的方法和系统 | |
| US20040158549A1 (en) | Method and apparatus for online transaction processing | |
| US6625602B1 (en) | Method and system for hierarchical transactions and compensation | |
| JP3732113B2 (ja) | トランザクション制御システム、方法及びプログラム | |
| US9805088B2 (en) | Constraint-based consistency with snapshot isolation | |
| US6061708A (en) | System and method for supporting mixed-phase transactions in an object-oriented environment | |
| JP3512439B2 (ja) | チェックイン・チェックアウトモデルにおける施錠方式 | |
| US6389431B1 (en) | Message-efficient client transparency system and method therefor | |
| WO2011119223A1 (en) | System with multiple conditional commit databases | |
| JP2011003200A (ja) | 長時間のトランザクションを管理する方法およびシステム | |
| CN119066078B (zh) | 分布式锁的处理方法和装置 | |
| Frank | Evaluation of the basic remote backup and replication methods for high availability databases | |
| CN110399429A (zh) | 一种分布式事务处理方法和系统 | |
| JP3611110B2 (ja) | 先日付完結処理のシステム、方法、プログラム及びこれに用いる取消再カットメイン処理用プログラム並びに資源利用最適化システム、プログラム及びこれに用いる取消再実行メイン処理用プログラム | |
| US8108273B2 (en) | Replicating data in financial systems | |
| JP3471728B2 (ja) | 先日付完結処理システム及び方法 | |
| Jacobsen et al. | Information management in creative engineering design and capabilities of database transactions | |
| JP2004272926A (ja) | 先日時付完結処理システム | |
| JP3941946B2 (ja) | 先日付完結処理システム及び取消再カットメイン処理用プログラムを記録した記録媒体 | |
| US20060294006A1 (en) | Business transaction process controller for composite transactions | |
| JPH10232809A (ja) | トランザクション処理システム | |
| CN120447876A (zh) | 一种银行系统多维拆分优化方法及可配置处理平台 |
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 |