2

これはかなり理論的な質問です。

私のサービスクラスでは、何らかの理由で操作が実行できない場合、原因が誤った入力または予期されチェックされたその他の条件であっても、常にロールバックを行う傾向があります。

Open Session in View パターン (OSIV) を使用する Web アプリケーションでは、セッションが閉じられ、後続の遅延読み込み操作が失敗するという厄介な副作用があります。リクエスト中のある時点でエラーが発生した場合にのみ、リクエストの最後にセッションをロールバックするために、醜い配管コードを作成する必要があります。

これは私に考えさせました：何かが本当にうまくいかなかった場合、ロールバックは例外的な手段であるべきですか？条件が満たされない場合、サービスメソッドはデータが書き込まれたり変更されたりしないことを自分で確認する必要がありますか? 入力の検証が成功したが、サービス メソッドが選択された入力が不正であると判断したときに、フロントエンド レイヤーがモデル オブジェクト (フォームなど) を更新する場合の対処方法は? たとえば、Hibernate は、ロールバックが行われない場合、デフォルト設定でこれらの変更を自動的に保持します。

ご意見、アドバイスお待ちしております！

4

1 に答える 1

2

私の意見では、反対の方法で考える方が良いでしょう。最初にエラー条件を取得し（例外が発生するか、nullが返される可能性があります）、次にこのエラーの場合にロールバックが役立つかどうかを判断します。 。

非常に重要な質問の1つは、トランザクション処理を誰が行っているかということです。それはあなたのサービスの呼び出し元によって行われるのですか、それともサービス自体で行われるのですか（つまり、すべてのサービス呼び出しはそれ自体のトランザクションです）。

A）呼び出し元がトランザクション処理を実行している場合：
このサービスを呼び出す前に呼び出し元が実行した他のステートメントもロールバックするため、サービスはロールバックを実行する必要はほとんどありません。呼び出し元は、サービスのエラーを通常の場合と見なして続行する場合があります。その場合、データベースステートメントが失われてはなりません。エラー後に呼び出し元が続行できない場合、トランザクションをロールバックするのは呼び出し元の仕事です。
これは、サービスが不完全なデータをデータベースに書き込んではならず、書き込む前に考えられるエラー状態をチェックする必要があることを意味します。
それでも、サービスのロールバックが役立つ場合が2つあります。-
エラー状態は、間違いなくプログラミングエラーの結果です。
-ロールバックせずにエラー状態を処理することは、サービスで多大な労力を要します。この場合、呼び出し元が注意を払う必要があるため、Javadocにロールバック条件を文書化することが非常に重要です。

B）サービスがトランザクション処理を行っています。各サービス呼び出しは、それ自体のトランザクションです
。サービスは、自由にロールバックを実行できます。サービスが最初に条件をチェックしてデータを書き込まない場合、またはロールバックを実行する場合、結果は同じであり、呼び出し元には表示されません。データが書き込まれる場合、サービスはコミットまたはロールバックのいずれかを実行する必要があります。例外がスローされた場合、呼び出し元はこの場合に書き込まれたデータを期待しないため、ロールバックを強くお勧めします。

ちなみに、Sessionオブジェクトで例外がスローされた場合、Hibernateは自動的にロールバックを実行します。

于 2012-03-14T11:04:27.437 に答える