大規模なデータベーストランザクションに最適なソリューション
メインフレームレガシーシステムで実行されているCOBOL CICSプロセスがあります。このプロセスは、並行性の高いDB環境で2Kを超えるDMLを実行します。各CRUD操作の後、その結果を使用してさらに計算が行われ、その後CRUD操作が再度実行されます。このプロセス全体はトランザクションブロックの下で実行されるため、正常に完了する前にエラーが発生すると、DBの変更セット全体がロールバックされ、プロセスの各ステップが最後まで成功すると、コミットが行われます。 COBOLプログラムは、このトランザクションの巨大さのために他のプロセスがDBリソース（ロック、ストールなど）を使い果たさないように、完了または失敗に20奇数秒以上消費しないように書かれています。
このレガシーアプリケーションをJava SOAP Webサービスとして公開するように依頼されました。私の3つのアプローチは次のとおりです。
Javaコードのサービスレイヤーは、入力パラメーターを使用してメッセージをキューに送信し、既存のCOBOLプログラムはキューからメッセージを選択してトランザクションを実行します。 Javaレイヤーは非同期でキューにpingを送信し、COBOLプロセスから結果を取得すると、コントローラーに送り返します。
DBトランザクションを含むCOBOLプロセスによって実行されるジョブを模倣するストアドプロシージャを記述し、SPサービスレイヤーからJavaを呼び出します。
Javaサービス/ DAOレイヤー内のビジネスロジックと、Springトランザクションブロック内のトランザクションを記述します。
レガシーCOBOLプログラムへの依存を意味するため、ビジネスは＃1アプローチを望んでいません。私はここに2つの疑問があります：
パフォーマンスの観点からSPの方が優れていることを理解しています。しかし、SPは、トランザクションブロック内で2K以上の奇数DMLを処理でき、少なくともCOBOLプロセスにかかる時間と同等の時間でジョブを実行できますか？はいの場合、DBは非常に並行しており、他のプロセスが原因で他のプロセスが枯渇したくないので、DBリソースのロックを解放するのに十分効率的です。
Javaコードからこの規模のDBトランザクションを実行したことがなく、Springトランザクションブロックが1つのブロックに2K DMLを効果的に保持できるかどうか疑問です。たとえそれがCOBOLやSPの速度と一致しないと確信している場合でも、レコードなどのロックを取得し、長時間同じものにアクセスする必要がある他のプロセスを枯渇させる可能性があります。
トランザクションは特定のDBテーブルではなく、重要な財務データを含む20の奇数の異なるテーブルに分散されます。 Springトランザクションブロックのチャンクで多数のCRUD操作を分割することを考えていましたが、Javaでロールバックロジック全体をコーディングするのは大変な作業でしたが、問題はありませんが、私の主な懸念はDBから他のプロセスをロックすることですその間アクセス。
私はJavaの開発者であり、RDBMSの知識は乏しく、COBOLの知識はほとんどありません。誰かが私に正しい方向を教えてくれて、自分で解決策を見つけられるようにしてくれるとありがたいです。
100のうち99回は、歯を磨いて既存のCOBOLコードを再利用することだと思います。舞台裏にはかなり複雑なロジックがあるようです。実際に最新の正確な仕様がない限り、すべてのニュアンスでロジックを再現するのに問題が生じる可能性があります。 Beanカウンターはレガシーコードとのバグごとの互換性を必要とするため、これは金融アプリケーションでは悪いモジョです。
したがって、最初のストップとして、レガシープロセスをラップするか、フロントエンドと統合するために何が必要かを真剣に調査することをお勧めします。 Micro Focusから利用可能なCOBOL-Java統合オプションをご覧ください。
既存のコードをリサイクルできない場合は、重大な問題があります。 sprocはあなたが望むことをうまくやるかもしれませんが、何かが明らかに複雑でおそらく文書化が不十分なCOBOLアプリケーションの正確な動作を模倣するという問題があります。
置換プロセスが根本的に遅い場合を除いて、トランザクションで2000 DMLをラップすることは大きな問題にはなりません。 ETLプロセス全体をトランザクションにラップし、障害時にそれらをロールバックさせることができます。これは珍しいことですが、これを行う必要があるアプリケーションを見てきました。金融取引を分割することは、特にダブルエントリーシステムではノーノーです。ほとんどの場合、アトミックにコミットまたはロールバックする必要があります。単一のトランザクションに固執します。
COBOLアプリケーションが一度に1つのDMLを計算し、その結果を計算の次のステップで使用するという事実は、集合演算への変換には適していません。これを行ごとに実行し、高速に実行する方法を見つける準備をしてください。ストアドプロシージャがこれを行う方法である場合があります。使用しているDBMS（DB/2 for Z/OS？）はわかりません。
また、特にクライアント層で作業する必要がある場合は、XAトランザクション（Java.transactions API）およびJDBCにドロップダウンする必要がある場合もあります。 2000行ベースの操作で優れたパフォーマンスが必要な場合は、フレームワークを下回る必要がある場合があります。
SOAの約束の1つは、抽象化レイヤーとサービスバスを通じてレガシーシステムを活用することです。
最初に、ビジネスはレガシーアプリケーションをWebサーバーとして公開するように要求していると言いますが、ビジネスはオプション1を望んでいないと言います。これは、レガシーCOBOLプログラムに依存しているためです。だから何彼らは本当にあなたにそれからそれを書き直すことですです。
その場合、最善の方法は＃2で、ストアドプロシージャの記述を書き換えます。
これには、Java/DAOアプローチに比べて次の利点があります。
PL/SQL、PL/PgSQL、またはTransact SQLなどのストアプロシージャ指向の言語（どのRDBMSを使用しているかはわかりません）目的固有（汎用目的で）- JavaよりCOBOLに似ている。命令セットが少なく、文法が単純であり、一般に、Javaの場合よりも、PL/SQLでCOBOLプログラムの行ごとの変換を記述する方が簡単です。
ストアドプロシージャデータベースサーバーで実行、つまり、アプリケーションサーバーまたはクライアントでJavaのクライアントコードよりも高速に実行）.
速度が非常に重要であるため、DAOのオーバーヘッド/JDBCを使用しないほうが効率的です。
ブロックとトランザクションを最適に処理するまさに、まさにその目的のために、まさにその言語がRDBMSに組み込まれていること。
私はこれらの4つの利点の最初の1つが最も重要なものであると信じています。また、プログラミングを行わないビジネスエキスパートがおそらくコードを理解し、数式やビジネスルールの検証を支援できるという点で、追加の利点があります。
私は重要なアプリケーションのためにOracleのPL/SQLプログラミングのかなりの量を自分で実行しましたが、それは非常にうまく巨大なトランザクションを処理することができると言うことができます。そうだと思いますSPはその目的に適したツールです。