7

EntityContextの存続期間の管理については、多くの質問がありました。

例:LINQのコンテキストをエンティティにインスタンス化する

私は、エンティティコンテキストは作業単位と見なされるべきであり、したがって再利用されるべきではないという結論に達しました。素晴らしい。

しかし、データベースアクセスを高速化するための調査を行っているときに、このブログ投稿に遭遇しました...

EntityFrameworkのパフォーマンスの向上

投稿では、他のフレームワークと比較してEFのパフォーマンスが低いのは、新しいEntityContextオブジェクトが必要になるたびにEntityConnectionオブジェクトが作成されることが原因であることが多いと主張しています。

これをテストするために、 Global.asax.cs Application_Start()で静的EntityConnectionを手動で作成しました。

次に、ステートメントを使用してすべてのコンテキストを次のように変換しました

using( MyObjContext currContext = new MyObjeContext(globalStaticEFConnection)
{
   ....
}

私の知る限り、これはエラーなしで少しスピードアップしたようです。

しかし、これは安全ですか?

アプリケーション全体の静的EntityConnectionを使用すると、競合状態が発生しますか?

よろしく、カービン

4

2 に答える 2

7

EntityConnectionは、スレッドセーフではないことが文書化されています。それらをプールすることはできると思いますが、多くのスレッドが関係するため、Webアプリケーションに単一の静的接続を使用することはできません。

于 2010-04-05T15:35:49.310 に答える
2
  • EFコンテキストがアプリケーション全体である場合、ユーザーAが変更を加え(コミットされていない)、ユーザーBが変更をコミットしたことを考慮してください。ユーザーAとBの両方が同じインスタンスを使用するため、すべての変更がデータベースにコミットされます。

  • 私のプロジェクトでは、EFコンテキストのWebRequestごとのインスタンスを実行しました。コンテキストオブジェクトは、Webリクエストの開始から終了まで静的であり、そのリクエスト内のすべての操作は同じEFコンテキストで機能します。これにより、上記の問題なしに処理が大幅に高速化されました。

これを実装する1つの方法は、DIコンテナー(私はUnityを使用しています)を使用してEFコンテキストの存続期間を管理することです。Unityでは、Webリクエストごとのライフタイムマネージャーがすぐに使用できるわけではありませんが、これを行う方法を示す記事がたくさんあります。

HTH。

于 2010-04-04T18:46:22.487 に答える