問題タブ [session-per-request]

Webアプリに対して実行しようとしているリファクタリングについての洞察と考えが必要です。

最初は、HttpApplicationでOn_BeginRequest / On_EndRequestを使用してセッションを作成および破棄することにより、NHibernateおよびActiveRecordでリクエストごとのセッションパターンを使用しました。後で、DB関連の例外がモノレールコンテキストの外にスローされたことに気付きました。つまり、レスキューが開始されませんでした。別の副作用として、NHibernateセッションの作成を完全にスキップするオプションがありませんでした。アクション。場合によっては望ましいでしょう。

そこで、ベースコントローラーのInitialize（）/ Contextualize（）でセッションを作成するように書き直し、ベースコントローラーのDispose（）にそれらを配置しました。また、レスキューコントローラーでセッションをロールバックして、DBへの半分の書き込み変更を防ぎます。ここまでは順調ですね。Dispose（）でこれを行う理由は、遅延読み込みの理由と、セッションを取得する必要のあるビューコンポーネント（ viewcomponentsですが、Dispose（）がないようです...）

ただし、DBでトランザクションを開始したときに、ロールバックもコミットもされていないデッドロックの問題が発生しており、主にこのアプローチで混乱が生じたために、頭を悩ませることができません。 。

だから私はこの記事を見つけました：http：//hackingon.net/post/NHibernate-Session-Per-Request-with-ASPNET-MVC.aspx

そして、「フィルター、MonoRailでも使用できます！」と思いました。BeforeActionとAfterRenderingを開始できるからです。

私の質問は次のとおりです。

1. フィルタで例外が発生した場合はどうなりますか？
2. アクションまたはレンダリングで例外が発生した場合でも、AfterRenderingは起動しますか？
3. このアプローチをお勧めしますか？そうでない場合は、代わりにどのような提案をしますか？

どんなポインタでも大歓迎です！

WCFアプリケーションにリクエストごとのセッションモデルを実装しようとしています。このトピックに関する無数のドキュメントを読みましたが、これの完全なデモンストレーションがないようです。私は実際にこのようないくつかの非常に有用な記事に出くわしました：

NHibernateのISession、単一のWCF呼び出しを対象

しかし、これらはすべてNHibernateとNinjectにWCF固有の実装がなかった昔のものであり、カスタムサービスプロバイダーなどを実装することで私が必要とするものを達成しました。NinjectとNHibernateの両方が現在WCFをサポートしているので、一貫性を保ちたいと思います。それらのモジュールを使用することによって、しかし私はここに行き着きました...

基本的なセットアップとフローは次のようになります。

1. nhibernate構成でCurrentSessionContextをWcfOperationSessionContextに設定します
2. サービスの開始時、リクエストの開始時、または初期化時間の前後の任意の場所で、セッションを開き、現在のコンテキストにバインドします
3. リポジトリは、SessionFactory.GetCurrentSession（）メソッドを使用して現在のセッションインスタンスを取得します
4. ライフサイクルの最後にセッションのバインドを解除して閉じます

私の最初の問題は、バインディングを処理するためにwcfライフサイクルにアクセスできなかったことでした。ninjectコードを少し掘り下げた後、あまり変更せずにServiceHostのOpening / Closingイベントにメソッドをフックすることができましたが、スレッド静的であるため、OperationContextにアクセスできませんでした。

後で、asp.net互換性を有効にして、Application_BeginRequestとApplication_EndRequestを使用しようとしましたが、非常に有望に見えましたが、httpリクエストではなく、サービスインスタンスにバインドする必要があるため、これが最善の解決策ではないと思います。

ninjectの組み込みのwcf拡張ライブラリを使用してこれを達成した人はいますか？または私が間違っているかもしれないことについてのアイデアはありますか？

ねえ、私は 4 層のソフトウェア システム (プレゼンテーション - JSP、問題ドメイン、アプリケーション ロジック、永続性) を構築しており、何かをしたいたびにトランザクションを作成しないように、リクエストごとにトランザクションを休止状態にしたいと考えています。また、変更されたプロパティのみが更新されるように、オブジェクトを使用してデータを追跡することもできます。

私はこのためのフレームワークとして春を見てきましたが、これを実装したいと思っていましたが、私のグループはそれを拒否し、使用できません。

JTA も調べましたが、Bean を使用していないため、JTA がどのように役立つかわかりません。

トランザクションを閉じたり開いたりするために呼び出すメソッドを持つなどの解決策を考えましたが、もっと洗練された解決策があるようです。

私のシステムに基づいて、リクエストごとにトランザクションを維持する最良の方法は何ですか?

タイトルで述べたように、Webリクエストごとにセッションを実装したいと思います。私のセッションプロバイダーはこのように構成されています（この設定を変更することに興味はありません）。

Global.asax.cs内には、Web要求ごとのセッションに関連する次のコードがあります。

Webアプリケーションをデバッグすると、次のエラーが発生します。現在のセッションコンテキストが構成されていません。 global.asax行CurrentSessionContext.Bind（session）;を参照するErrorMessage

更新 追加されまし.ExposeConfiguration(c => c.SetProperty("current_session_context_class", "web")) た。コントローラーからデータを取得する際に、次のような エラーメッセージが表示されます。エラーメッセージ：セッションが閉じられました。オブジェクト名：'ISession'。

コントローラーコード：

例えば。私のセッションファクトリはMyDomain.SessionProviderクラスにあります。セッションを開くことができますusing ISession session = SessionProvider.Instance.OpenSession()

ステップ：SessionProvider.cs

ステップ：Global.asax.cs

アプリケーション開始

App_BeginRequest

EndRequest破棄セッション

Step3.HomeController 次のような現在のセッションを使用する必要があります

さて、descのように私のコントローラーでデータを取得しようとしています。ステップ3で。セッションが閉じられたというエラーメッセージが表示されました。global.asax内のApplication_EndRequestブロックを削除しようとしましたが、トランザクションがセッションでラップされましたが、成功しませんでした。それでも同じエラー。

2番目/副次的な質問：このパターンは広く受け入れられていますか、それともmvcコントローラーのカスタム属性内にラップする方が良いですか？ありがとう。

更新：現在のセッションをインラインでインスタンス化しようとしたときにコントローラーで

次のエラーが発生します：

皆さん、 Open Session in ViewとSession per requestパターンの違いは何ですか? Spring MVC と Hibernate を使用しています。ここではトランザクション境界については話していません。リクエストごとのセッションは 1 セッション:1 tx のようです。しかし、OSIV の場合、1 つのセッションがあり、複数のトランザクション (サービス呼び出しごとに 1 つ) があります。誰かがこれに光を当てることができますか？

私が取り組んでいる MVC 3 プロジェクトは、現在のセッションの最後に行った挿入/更新呼び出しをコミット/ロールバックします。これは、複数の挿入を行っている現在を除いて、ほとんどの場合うまく機能します。

csv がサイトにアップロードされると、各レコードが解析されて DB に挿入されます。問題は、1 つのレコードの挿入に失敗した場合、以前のすべてのレコードがロールバックされ、その後のすべての試行がエラーで失敗することです。

セッションごとのリクエストを無効にするにはどうすればよいですか (または、何らかの方法でトランザクションを「再開」する必要がありますか)?

詳細を編集する

リクエストごとのセッションは、IHttpModule を実装するクラスで構成されます。このクラスは、HttpApplication コンテキストと UnitOfWork クラスを受け取ります。これは、コミットとロールバックが発生する場所です。

上記の UnitOfWork は、StructureMap を使用してリポジトリに挿入されます。

私が言ったように、この動作はサイトの残りの 99% で問題ありません。要求ごとのセッションのトランザクションを無視するには、この一括更新を取得する必要があります。または、新しいレコードごとにトランザクションを手動で再開する必要があります。方法がわかりません。

Spring MVC3とHibernate4.1を使用して宣言型トランザクション管理を取得し、リクエストの全期間にわたってオープンセッションを提供しようとしています。データアクセス用の「マネージャー」レイヤーは1つだけで、セッションを直接使用します。これには@Transactionalの注釈が付けられており、このレイヤーを終了するとセッションが閉じ、コントローラーで遅延読み込みの例外が発生します。

そこで、OpenSessionInViewFilterフィルターを追加しました。ログには、このフィルターが正しく構成されていることが示され、このフィルターがセッションを開いていることも示されています。残念ながら、私のマネージャーレイヤーは、以前と同じように、とにかく独自のセッションを開いたり閉じたりします。コントローラーで同じ遅延読み込み例外が発生します。

編集：ログで、フィルターセッションを開き、HibernateTransactionManagerセッションを開き、HibernateTransactionManagerセッションを閉じ、遅延読み込み例外を取得してから、フィルターセッションを閉じていることに注意してください。したがって、遅延読み込みの例外中にどこかに開いているセッションがあることはわかっていますが、オブジェクトは他の閉じたセッションに関連付けられたトランザクションで読み込まれました。

マネージャークラスから@Transactionalを削除すると、そのレイヤーからセッション管理が削除され、フィルターにその役割が果たされると思いましたが、sessionFactory（）。getCurrentSession（）は単に閉じられたセッションを取得します。フィルタが提供するオープンセッションにアクセスすることはできません。

OpenSessionInViewFilterの明確に開いているセッションにアクセスするにはどうすればよいですか？

springapp-servlet.xml

web.xml

hibernate-context.xml

manager.java

controller.java

そして、コントローラーで発生する私の例外は、マネージャークラスにロードされ、そのコントローラーに渡されたオブジェクトの最初のプロパティ読み取りで発生します。

org.springframework.web.util.NestedServletException：リクエストの処理に失敗しました。ネストされた例外はorg.hibernate.LazyInitializationExceptionです：プロキシを初期化できませんでした-セッションがありませんorg.springframework.web.servlet.FrameworkServlet.processRequest（FrameworkServlet.java:894）org.springframework.web.servlet.FrameworkServlet.doGet（FrameworkServlet.java： 778）javax.servlet.http.HttpServlet.service（HttpServlet.java:617）javax.servlet.http.HttpServlet.service（HttpServlet.java:717）org.springframework.orm.hibernate4.support.OpenSessionInViewFilter.doFilterInternal（OpenSessionInViewFilter。 java：119）org.springframework.web.filter.OncePerRequestFilter.doFilter（OncePerRequestFilter.java:76）

私はこれを何時間も研究してきました。私が見つけることができるのは、Hibernate3を使用したソリューションとHibernate4のセッション/トランザクション理論に関する詳細な説明を例なしで組み合わせたものだけです。

何かご意見は？

更新：修正済み！

これを見つけました：

SpringMVCOpenSessionInViewInterceptorが機能しない

残念ながら、そこでのOPには役立ちませんでしたが、私には役立ちました。特に、これは：

「dispatcher-servlet.xmlにapplicationContext.xmlをインポートせず、代わりにContextLoaderListenerを使用してロードする方がよいでしょう。」

これは私の構成に適用され、私が上に投稿したものとまったく同じですが、代わりに

springapp-servlet.xmlで、ContextLoaderListenerを次のように変更しました。

それにかかったのはそれだけでした

OSIVで作成されたセッションに戻ります。そして、実際、これらの素敵な小さなログ行を見つけたので、作成されていた2番目のセッションはもうありません。

これは、@ Transactionalサービス層の外では、OSIVで作成されたセッションが正常に機能しており、そのために新しいトランザクションが開始されたことを示しています。

これが他の誰かに役立つことを願っています。何時間かけて取り組んだのか考えたくありません。

自分のアーキテクチャで作業単位が間違って設定されている可能性があると思います。これが私が現在持っているものです（順序を示すためにインデントされています）：

ここでは、NHibernateを使用してクラッドを実行するためにさまざまなサービスを呼び出します。データベースに変更（更新/保存）を行う場合は、次のコードを呼び出します。

HttpRequestが終了したら、次の手順を実行します。

大規模なバッチプロセスをロールバックできるという問題が発生しています。上記のように、CRUDレイヤーでトランザクションをコミットしているため、トランザクションはアクティブではなくなり、UnitOfWorkでロールバックしようとすると、トランザクションがすでにコミットされているため、何も実行されません。CRUDレイヤーでコードをコミットする理由は、データベースを長時間ロックすることなく、データをできるだけ早く永続化できるようにするためです。

上記のような状況で取るべき最善の行動方針は何ですか？バッチジョブをコミットせず、ジョブの最後にコミットを処理する特別なCRUD操作を行うだけですか、それともUnitOfWorkとSession Per Requestのロジックに欠陥がありますか？助言がありますか？

Tapestry5（java webframework）とHibernateで作成されたWebアプリケーションがあります。今、私は楽観的ロックを追加しようとしています。そこで、バージョン属性を追加し、楽観的ロックが機能するようにしたので、それは簡単で高速でした。

しかし、私のWebアプリケーションは「要求ごとのセッション」パターンで動作するため、この楽観的ロックを利用するための最良の方法がわかりません。

何が起こるのですか：

UserAは、entityA（バージョン1）からの値がロードされたフォームでページを開きます。

UserBは、entityA（バージョン1）からの値がロードされたフォームでページを開きます。

UserAはいくつかの値を変更し、フォームを送信します。->新しいリクエストはentityA（バージョン1）を取得し、変更をコミットします（entityAはバージョン2になりました）

UserBはいくつかの値を変更し、フォームを送信します。->新しいリクエストはentityA（バージョン2）を取得し、変更をコミットします（entityAはバージョン3になりました）

何が起こるべきか

UserBの変更はコミットしないでください。ただし、リクエストごとのセッションパターンのため、Hibernateの楽観的ロックエラーが発生する可能性のある時間枠は、送信からコミットまでの新しいリクエストからの期間に短縮されます。これは望ましい結果ではありません。

可能な解決策

いくつかの調査の後、私は次のことを発見しました：

• エンティティバージョンを使用してフォームに非表示フィールドを追加します

この値を使用して、コミット前にエンティティのバージョンを設定できますが、Hibernateのドキュメントではこの値の設定を推奨していません。また、エンティティがデタッチされて再接続された場合にのみ機能します。それ以外の場合、手動で設定されたバージョン値はHibernateによって無視されるためです。

次に、このバージョン値を使用して、フォームがレンダリングされたときのバージョンが、送信時にリクエストにロードされたエンティティのバージョンと同じであるかどうかを手動で確認できます。次に、必要に応じて自分でOptimisticLockingExceptionをスローします。

• デタッチされたエンティティをHttpSessionに配置するので、送信時に再度ロードする必要はありません。

結論

これらの方法は機能しますが、私にはあまり実用的ではなく、間違いを犯しやすいようです。だから私は他の人がこの問題をどのように実装しているのだろうかと思っています。