2

ASP.Net アプリケーション (Web フォーム) の NHibernate のトランザクション管理に関する調査を行っています。私が見つけたほとんどの記事は、リクエストごとのトランザクション アプローチを支持する傾向があります。私はリクエストごとのセッションを理解していますが、完全に賛成です。ただし、リクエストごとのトランザクションの背後にある理由は正確にはわかりません。

私のアプリケーションは version-field を使用して並行性チェックを行います。StaleObjectException などの問題がスローされた場合、これは を呼び出すとスローされますTransaction.Commit()。私の問題は、これがリクエストの最後にある場合、問題のあるコードが実際にどのメソッドにあったかを簡単に知ることができず、問題からロールバックするのが非常に難しいことです.

たとえば、StaleObjectException では、通常、更新されたデータを使用してメソッドを再実行するだけで済みます。

これに関するアイデアと、トランザクション管理の実践はありますか? 私は、ビジネス ロジックに基づいて、できるだけ多くのトランザクションを開くことを好みます。複数のトランザクションの問題は、実際にトランザクションを開始/終了する場所です。

4

1 に答える 1

2

要求ごとのトランザクションのパラダイムは、一歩下がって Web アプリケーションの根底にある性質を考えると理にかなっています。これは要求/応答システムであり、それ以上のものではありません。ユーザーが「何か」のリクエストを送信すると、アプリケーションはこれをアクションまたは一連のアクションの実行に変換します。その後、アプリケーションはユーザーに応答を送信して、現在の更新状態を示します。

このモデルでは、アプリケーションへのアクションの各リクエストはアトミックにすることができます (ほぼ間違いなくそうすべきです)。結局のところ、ユーザーの観点から、エラーが発生したときに何が失敗したかという概念は? リクエストは失敗しました。このような障害が発生した場合、アプリケーションは次の 2 つの方法で応答する必要があります。

  1. 要求の処理に関連する部分的な変更をロールバックして、永続化されたデータが「部分的」または「未定義」の状態のままにならないようにします。

  2. 何らかの理由でリクエストが失敗したことを (レスポンスで) ユーザーに通知します。

    私の問題は、これがリクエストの最後にある場合、どのメソッドが実際に問題のあるコードを持っていたかを簡単に知ることができず、問題からロールバックするのが非常に難しいことです.

コードで例を示してもらえますか? この問題は、アプリケーションの設計のトランザクション構造以外の要素によって解決されるのではないかと思います。リクエストの処理が適切にアトミックまたはカプセル化されていない可能性があります。

(コメントは、以下がより個人的な意見である可能性があり、NHibernate の通常の動作であることを示しています)

たとえば、StaleObjectException では、通常、更新されたデータを使用してメソッドを再実行するだけで済みます。

私は確かにNHibernateの専門家ではありませんが、ここで言われていることを理解するのをためらっています. 通常、例外が発生した場合、単に「再試行」するだけでは、例外を処理するのに適していません。

于 2012-08-11T12:21:10.813 に答える