DbContextとDispose

とその周辺のお話
3
neuecc @neuecc

そういえばDbContextっていつDisposeするのが解なのでしょうか。Repositry Patternの例とか、フィールドに抱えてスルーが多い感で、そもそもDbContextってDisposeとかドーデモイイ系でしょうか?(その辺全然知りません)

2012-09-12 11:52:59
Tatsuro Shibamura @shibayan

Per Request で DbContext が作成されるようにして、Application_EndRequest で DbContext が作成されていたら Dispose(ドヤァ

2012-09-12 11:55:21
Hiroaki SHIBUKI @hidori

@neuecc DbContext との繋がりをいつまでも持ってるのは諸刃の剣だと思うんで、僕は原則 Repository に生やすメソッドは static です。

2012-09-12 11:56:44
Hiroaki SHIBUKI @hidori

@shibayan async, await 使う場合とか、1個のコンテキストの使いまわしで大丈夫?

2012-09-12 11:58:09
neuecc @neuecc

@shibayan おー。(EFじゃないのですが)各メソッドで毎回usingまんどくせ、なので、そんな感じで行きたいですねー。

2012-09-12 11:59:00
Tatsuro Shibamura @shibayan

@neuecc 実際のところは Dispose しなくても問題なさそうですけどね。1 つの DbContext を長時間使いまわしてたら逆に死にます

2012-09-12 12:00:09
Hiroaki SHIBUKI @hidori

コネクションプールがあるので、コネクションの生成・破棄のコストはあまり考えなくても大丈夫。

2012-09-12 12:00:17
Hiroaki SHIBUKI @hidori

@shibayan @neuecc コネクションプールがあるから生成・破棄のコストは心配しなくていい反面、たまーに腐ったコネクションを引いてしまうリスクがあります。

2012-09-12 12:01:15
Kazuhiko Kikuchi @kazuk

@hidori @neuecc 自分の場合 interface IHogeRepository : IDisposable で上から Dispose 呼ばれた時に Dispose するようにしていますよ

2012-09-12 12:01:55
Hiroaki SHIBUKI @hidori

@kazuk @neuecc 短い範囲でなら Repository を using でもいーと思うんだけど、短いんならレポジトリメソッド自体 static にして、その中で dbcontext を using のが話速いんじゃないかと。

2012-09-12 12:05:28
Hiroaki SHIBUKI @hidori

SQL Azure に対するクエリがこけた時は接続からやり直すことになるし、フェデレーションかかった仮想テーブルに対するクエリ実行のなんやらかんやらも Repository までで隠ぺいしときたいので、今の状況に落ち着いてます>じぶん

2012-09-12 12:06:49
Hiroaki SHIBUKI @hidori

単純なリトライは DAL 層に置いてた>おれ

2012-09-12 12:08:04
neuecc @neuecc

@hidori @shibayan 長時間というのは、1リクエストどころじゃなく長期、でしょうかー。DbContext自体はクエリ一個につきOpen/Closeでコネクションをプールに戻す・取り出しますよね。「面倒くさい」「DbContext自体の生成のコスト」かなあ。考慮点。

2012-09-12 12:08:28
Kazuhiko Kikuchi @kazuk

@hidori @neuecc 更新系のトランザクション範囲を複数のリポジトリにまたがって伸ばす必要無いならそれでOKだと思われるけど、トランザクション範囲はたいがいリポジトリをまたがる

2012-09-12 12:08:39
Tatsuro Shibamura @shibayan

@neuecc SignalR の Hub で 1 時間以上使ってた時、意味の分からないエラーが頻発して俺が死にました(何

2012-09-12 12:09:17
Kazuhiko Kikuchi @kazuk

ASP .NET MVCのControllerはIDisposableなんだからちゃんとDisposeの連鎖関係をつなげていけば問題にはならんはず http://t.co/S0nTE6jD

2012-09-12 12:10:09
Hiroaki SHIBUKI @hidori

@kazuk @neuecc 更新系トランザクション範囲を複数>そなんだけど、もっと上流まで持ち越すのも抵抗があって。。。ビュー作ってビューの更新にしえ逃げてるw

2012-09-12 12:10:50
Hiroaki SHIBUKI @hidori

@neuecc @shibayan 長時間>1個のコンテキストで複数のページ処理とかはありえないので、1回の接続で複数回のクエリ・更新実行するようなイメージです>じぶん

2012-09-12 12:12:38
Hiroaki SHIBUKI @hidori

DbContext の using って、どーして美しくなく見えるんだろう?

2012-09-12 12:12:59
neuecc @neuecc

@shibayan なるる、あ、こないだ聞いた話ですね!実に恐ろしいw

2012-09-12 12:13:51
Hiroaki SHIBUKI @hidori

せっかく OR マッピングしてるんだから、さらに上流のモデルに中身を「移し替える」なんてのは避けたいしなぁ

2012-09-12 12:15:59
oda shinsuke @shinsukeoda

リポジトリの1メソッド内でトランザクション完結したいなー。複数リポジトリ跨るのは、なんか単にORマッパーのDAO になってる感。自分的にはリポジトリはもっと大きい範囲のイメージがある。EF 使ってないから話題とずれてるかもだけど

2012-09-12 12:17:11
Hiroaki SHIBUKI @hidori

SQL Azure でなくても、DB がフェールオーバーした時はやっぱりアプリレベルでクエリのリトライ必要な時あるし。

2012-09-12 12:18:16
Hiroaki SHIBUKI @hidori

リポジトリの1メソッド内でトランザクション完結したいなー>同感。でも、異なるデータソースに所属する複数のレポジトリに対するトランザクションもありますからねー 会員管理が外出しとか

2012-09-12 12:20:19
oda shinsuke @shinsukeoda

@hidori なるほど!確かにそうですね。でも上の層が呼び出すのはそれもひっくるめた1メソッドが嬉しいなーと思ってます。

2012-09-12 12:23:18