0

次のようなものを返すストアド プロシージャがあります。

PrevLocationId | 前の場所名 | 次の場所 ID | 次の場所名 | バッチ ID | 接続 ID

それぞれ bigint と int である BatchId と ConnectionId の 2 つのパラメーターを受け取ります。

このストアド プロシージャは、Entity Framework の最初のバージョンを使用して C# アプリで呼び出されています。

アプリ内には TransactionScope があり、この sproc をさまざまなパラメーターで実行するループ内にあります。

私のテストでは、次のパラメーターを使用してループが 2 回実行されるアプリケーションの欠陥を確認しています。

最初の実行: BatchId = 34、ConnectionId = 20
2 回目の実行: BatchId = 34、ConnectionId = 23

sproc 呼び出しにブレークポイントを設定し、それをデータベースで直接実行すると、両方の実行で正しい結果が得られますが、アプリケーションに実行を許可すると、常に最初の実行から両方の結果が得られます。

データベースが各実行で正しいパラメーターを受け取っていることを SQL プロファイラーで確認しました。

同じ結果でトランザクションスコープを削除しようとしました。

エンティティ フレームワークが実行する奇妙なキャッシングがあるかどうか、またはそれにグリッチがあるかどうか、または返される結果に影響を与える可能性のある何かがあるかどうか、誰かが知っていますか?

他にどこを見るべきかわかりません。どんな洞察でも大歓迎です。

4

1 に答える 1

0

Entity Framework の最初のバージョンでは、ObjectContext.ExecuteFunction のマージ オプションのデフォルトが AppendOnly であり、それ以外に設定できなかったことが判明しました。

その場合、この問題を解決するために考えられる回避策は 2 つだけです。

  1. Ado .Net を使用して、ストアド プロシージャを呼び出します。
  2. ストアド プロシージャの最初のパラメーターとして Guid を追加して、Entity Framework が常に新しい呼び出しがあり、キャッシュされた結果を使用しないことを認識できるようにします。

Entity Framework バージョン 4 では、ObjectContext.ExecuteFunction にオーバーロードがあり、MergeOption を NoTracking に設定して、この種の問題を解決できます。

于 2012-12-13T16:17:22.623 に答える