3

少し前に、Spring AOPを使用してトランザクショナルなメソッドを定義するアプリケーションを作成しました。私は今、これがどれほど素晴らしいアイデアであったかについて考え直しています。私はマイナーなリファクタリング (メソッド シグネチャの変更など) の後に数回ヒットしましたが、これはもちろん、実際に問題が発生するまで明らかになりません (そして、論理的に一貫性のないデータベースがあります)。

だから私はいくつかのことに興味があります：

  1. 他の人は明示的なトランザクション管理に戻ることを決めましたか (例:@Transactional注釈を介して)?
  2. 何かが「壊れている」かどうかを識別するのに役立つ、ビルド プロセスの一部として使用できる便利なツールはありますか?
  3. 人々が AOP を使用してトランザクションを管理している場合、私が犯した間違いを回避するためにどのような手順を踏んでいますか?

私は IntelliJ IDEA を使用しています。これにより、装飾されたメソッドを参照できXML、メソッド名の変更とともに Spring 構成をリファクタリングできますが、これは必ずしも十分ではありません (たとえば、間違った場所のメソッドにパラメーターを追加すると、アスペクトが起動するかどうかに影響する可能性があります)。

4

3 に答える 3

4

私は現在、私が取り組んでいる 2 つの Java プロジェクトで宣言型トランザクション管理を使用しており、@Transactionalアノテーションを使用してトランザクション スコープが必要なメソッドを指定しています。私の意見では、柔軟性と堅牢性がうまく組み合わされています。単純なテキスト検索を介してどのメソッドがトランザクション動作をしているかを確認でき、必要に応じて分離属性と伝播属性を手動で調整でき、追加の入力量は実質的に無視できます。 .

それらのプロジェクトの 1 つで、アスペクトを介して実装されたセキュリティ/ロギングを使用しており、メソッドの名前を変更したりシグネチャを変更したりするときに、同じ障害に遭遇することがあります。最悪の場合、コントラクトにアクセスするユーザーのログ データの一部が失われ、あるリリースでは、一部のユーザー ロールがすべてのアプリケーション機能にアクセスできませんでした。大したことはありませんが、データベース トランザクションに関する限り、それだけの価値はないと思い@Transactionalます。とにかく、春は難しい部分を行います。

于 2009-03-08T23:02:25.403 に答える
2

(1) に関して: @Transactonal は、過去数年間に取り組んだすべてのプロジェクトでより実用的なソリューションであることがわかりました。ただし、非常に特殊なケースでは、Spring AOP を使用して、複数の JDBC 接続 / TransactionManager を使用できるようにする必要がありました。これは、@Transaction が単一のトランザクション マネージャーに関連付けられているためです。

(2) について: とは言っても、混合シナリオでは、壊れている可能性のあるコードを見つけるために多くの自動テストを行っています。Spring の AbstractTransactionalJUnit4SpringContextTests / AbstractTransactionalTestNGSpringContextTests を使用してテストを作成します。これまでのところ、非常に効果的なソリューションでした。

于 2009-03-09T00:25:51.663 に答える
0

私はより純粋主義者になりがちですが、単純な自動コミットを超えて、あらゆるトランザクション管理をデータベース自体の内部に保持しようとしています。ほとんどのデータベースは、トランザクション管理の処理に優れています。結局のところ、トランザクション管理は、データベースの目的の重要なコンポーネントの 1 つです。

于 2009-03-09T00:05:08.360 に答える