1

ODP.NETを使用してOracleデータベースからデータを読み取るWCFサービスがあります。このサービスはデータベースにも書き込みますが、間接的に、すべての更新と挿入は、 TransactionScopeでラップするCOM+を介してアクセスするビジネスロジックの古いレイヤーを介して実行されるためです。古い層は、ODP.NETではなくODBCを介してOracleに接続します。

私が抱えている問題は、Oracleが2フェーズコミットを使用し、古いビジネスレイヤーがODP.NETではなくODBCを使用しているため、データが実際にサービスレイヤーからの読み取りに使用できるようになる前にトランザクションが返されることがあることです。TransactionScope.Commit()

StackOverflowでもこのような問題を抱えているJavaユーザーに関する同様の投稿があります。

Oracleの担当者は、この問題について私ができることはあまりないと投稿しました。

これは、OLETx ITransaction :: Commit（）メソッドの動作が原因である可能性があります。2PCのフェーズ1（つまり、準備フェーズ）の後、すべてが成功 すると、リソースマネージャーが実際にコミットしていなくても、コミットを返すことができます。。結局のところ、成功した「準備」は、リソースマネージャーがこの時点以降に任意に中止できないことを保証するものです。したがって、リソースマネージャーがMSDTCから「コミット」通知を受信しなかったためにコミットできなかった場合でも（通信障害などが原因で）、コンポーネントのコミット要求は正常に返されます。テーブルから行をすぐに選択すると、選択を実行した後、データベースで実際のコミットが発生する場合があります。したがって、読み取りセマンティクスが一貫しているため、selectには新しい行が表示されません。「フェーズ1の成功後に成功をコミットする」最適化はMSDTCの実装の一部であるため、Oracleではこれについて何もできません。

だから、私の質問はこれです：

2PCの2番目の部分が実際にいつ発生するかを把握する際に発生する可能性のある遅延（タイトルの「asyc」）の問題に対処するにはどうすればよいですか。したがって、（間接的に）挿入したデータが実際に選択可能であると確信できます。Commit()呼び出しが戻った後？

大規模なシステムは、データをすぐに読み取る準備ができていない可能性があるという事実にどのように対処しますか？

4

1 に答える 1

1

トランザクション全体が準備され、TransactionManagerによってコミット結果が決定されたと想定します。したがって、最終的に（ヒューリスティックな損傷を除いて）リソースマネージャーはコミットメッセージを受信して​​完了します。ただし、これにかかる時間についての保証はありません。数日かかる場合があり、タイムアウトは適用されません。リソースマネージャーの準備で「コミット」に投票した場合は、集合的な結果を聞くのを待つ必要があります。

このような状況では、最も簡単なアプローチは「理解された、私たちが考えている」アプローチを取ることです。あなたの要求は理解されましたが、実際には結果がわかりません。それがユーザーに伝えます。はい、すべての正常な状況でリクエストは完了しますが、状況によっては、オペレーターが実際にトランザクションに手動で介入することを選択できます（そうすることでヒューリスティックな損傷を引き起こす可能性があります）。

さらに一歩進んで、新しいトランザクションを開始し、いくつかのクエリを実行して、データがそこにあるかどうかを確認できます。これで、結果画面にデータを入力する場合、クエリなどを自然に実行することになります。問題は、期待される結果がそこにない場合にどうするかということです。繰り返しになりますが、「最近のリクエストは処理中です。更新を押して、完了したかどうかを確認してください」とユーザーに伝えます。または、自動的に再試行します（自動再試行はあまり好きではありません。事実上、非同期操作であることをユーザーに教育することをお勧めします）。

于 2009-11-20T20:16:06.557 に答える