初めて春のアプリケーションを構築しています。並行性に関して多くの問題が発生しています。バックエンドの管理方法に何か問題があるのではないかと疑っています。私のバックエンド コードと私が見た例との唯一の違いは、マネージャー クラスです。
私のコードでは、モデル (hibernate で管理) とその上に DAO を配置して、モデルで CRUD/searching/etc を実行しています。私が見たコード例では、DAO を直接使用することはありません。代わりに、DAO を間接的に呼び出すマネージャー クラスを使用します。私には、これは無意味なコードの複製のように思えます。
これらのマネージャ クラスは何のためにあるのでしょうか。コードが「トランザクション」でラップされていると読んだことがありますが、なぜそれが必要なのですか?
トランザクションは、更新を「トランザクション」にするために使用されます。
例) ユーザーが Web ページをクリックすると、データベースで 13 のレコードが更新されます。トランザクションは 0 または 13 の更新を確実に実行し、エラーが発生するとすべてロールバックします。
マネージャーは、物事をやりやすくすることに取り組まなければなりません。コードを魔法のようにスレッドセーフにするわけではありません。DAO を直接使用すること自体は、スレッド セーフのバグではありません。
ただし、DAO のロジックを制限し、ビジネス レイヤーにできるだけ多くのロジックを配置することをお勧めします。DAO パターンのベスト プラクティスを参照してください。
複数のスレッドでうまく動作しないコードの小さな例を投稿していただければ、いくつかのアイデアを提案できますが、トランザクションやマネージャーだけでは問題を解決できません。
多くのアプリケーションには重要な要件があり、ビジネスロジックには、複数のリソース（たとえば、複数のDAO）へのアクセス、これらのアクセスの調整、およびこれらのアクセス間のトランザクションの制御が含まれることがよくあります（DAO1およびDAO2にアクセスする場合は、変更をコミットまたはロールバックする必要があります。分割できない作業単位）。
したがって、この複雑さを専用のサービスコンポーネントにカプセル化して非表示にし、ビジネスの動作を大まかにクライアントに公開するのが一般的です。
そして、これはまさにあなたが参照しているマネージャーが行っていることであり、それらはサービスレイヤーを構成します。
サービスレイヤーは、アプリケーションの境界[Cockburn PloP]と、クライアントレイヤーとのインターフェイスの観点から利用可能な一連の操作を定義します。これは、アプリケーションのビジネスロジックをカプセル化し、トランザクションを制御し、その操作の実装における応答を調整します。
DAO は、より大きなトランザクションの一部にすぎないかどうかを知る方法がないため、トランザクションを所有するべきではありません。
サービス層は、トランザクションが属する場所です。それらが「無意味なコードの複製」であると言うのは間違っています。