2

基本アーキテクチャ：それぞれが同じWCFサービスをホストするn個の物理ボックスが、ロードバランサーを開始しました。トランザクションをサポートしない単一のデータベースインフラストラクチャにヒットする各ボックス-質問しないでください:(

したがって、私のアプリのデータアクセス層では、分散トランザクションのいくつかの方法が必要です。私のオプションは何ですか？

私のシステムのクライアントは、基本的なWebサービス（BasicHttpBinding）と光沢のある新しいWCFクライアント（NetTcpBindingまたはNetNamedPipeBinding）を使用して通信するレガシーアプリになることに注意してください。

編集1

たとえば、物理ボックス1のWCFレイヤーへの単一の呼び出しがあります（例：EditEntity（...））。この呼び出しにより、データベースへの2回の書き込みがトリガーされます。最初の書き込みの後、別のクライアントが、2番目の物理ボックス上のWCFサービスの2番目のインスタンスで同じエンティティに対してEditEntity（...）を呼び出します。2番目のボックスで、この特定のエンティティのトランザクションがすでに実行されていることをどのように知ることができますか？

ありがとう。

4

1 に答える 1

2

続行するのに十分な金額を提供したかどうかはわかりませんが、正しく読んでいれば、WCF サービスを介してトランザクションをサポートできることを確認しようとしているのですか? DB はトランザクションをサポートしていませんが、WCF エンドポイントはロード バランサーの背後にありますか? これは正しいですか？もしそうなら....

DB にはトランザクション サポートがないため、WCF 層に移動します。これは、WCF サービスへの 1 回の呼び出しでトランザクションを十分に網羅できるように、メソッドの粒度が粗いレベルであることを示唆しています。トランザクションを複数の WCF 呼び出しに分散しないでください。問題が発生します。

更新: 接続間の永続性を保証するロード バランサーで使用できる戦略がありますが、ここでは役に立ちません。EditEntity() を連続して呼び出していて、最初のエントリがトランザクションの開始で、2 番目のエントリがトランザクションの完了である場合、サービスの粒度が十分ではありません。

これら 2 つの呼び出しを 1 つのメソッド、つまり EditEntityComplete() に統合します。

2 つではなく 1 つのメソッドを作成できない理由はありますか?

更新 #2: 問題の言い換え - 単一のメソッドが、トランザクションをサポートしないデータベース内でエントリを実行します。問題のメソッドは、順番に完了する必要がある一連のステップを実行します。WCF メソッドは、適切な順序でのステップ完了に違反する同時実行競合の機会を表します。

これに基づいて、関数からの戻りデータが不要であると仮定して、WCF エンドポイントからの要求をログに記録できる非同期キューを検討してください。次に、単一のバックグラウンド プロセスからキューを処理します。

最終改訂:

データ ストアを変更しないという要件を再検討してください。

複数のクライアントの要件、データ ストアでのスケーリング、負荷分散、およびトランザクション サポートの必要性を考えると、最終的な提案は、データベースを変更することです。これを理解することは静的な要件ですが、多くの単純なデータベース プラットフォームが提供するトランザクション サポートを実装しようとすると、多くの労力が費やされます。この機能を再作成しようとすることには、利点はほとんどありませんが、多くの欠点があります。

于 2009-03-13T18:09:51.997 に答える