問題タブ [transactionmanager]

別のアプリケーションでユーザーを作成する、作成したリモート サービスに正常に到達 (デバッグ) しましたが、applicationUserDao.save(user); という行で爆発します。このエラーで：

ユーザーを保存しようとしているアプリケーションの transactionManager は次のようになります。

それは services.xml にあります。私がアクセスしているこのサービス用に追加した remote-servlet.xml には、次の行が含まれています。
<context:annotation-config/>

私が一番上に持っているサービス実装クラスでは： @Autowired private ApplicationUserDao applicationUserDao;

context:annotation-config を使用すると、それがなくても自動配線できます(context:annotation-config) 上記のエラーは発生しなくなりました。applicationUserDao が null であるため、null 例外が発生します。私は春と休止状態の構成の初心者です。他のトランザクションマネージャーがどのように読み込まれてservices.xmlのものと競合するのか正確にはわかりません。自動配線なしで applicationUserDao.save() を使用する方法がわかりません。これらがどのように衝突しているかについての提案や情報は素晴らしいでしょう:)

解決策を提供するための編集: Manuel Jordan に感謝<tx:annotation-driven/>します。remote-servlet.xml に追加しました。私も固執し<context:annotation-config/>ました。今は完璧に動作します:D

Spring + Hibernate とトランザクション アノテーションの使用。

私は以下をテストしようとしています：

1. User オブジェクトを変更するメソッドを呼び出してから、@Transactionalサービス メソッドを呼び出して永続化する
2. DB からオブジェクトを読み戻し、メソッドの後でその値が正しいことを確認します

私が抱えていた最初の問題は、ステップ 2 で User オブジェクトを読み取ったときに、Hibernate レベル 1 キャッシュ内のオブジェクトが返されただけで、実際にはデータベースから読み取られなかったことです。

したがって、セッションを使用してオブジェクトをキャッシュから手動で削除し、データベースからの読み取りを強制しました。ただし、これを行うと、オブジェクトの値は単体テスト内で永続化されません (指定した設定により、テストの完了後にロールバックすることがわかっています)。

サービスメソッドの呼び出し後にセッションを手動でフラッシュしようとしましたが@Transactional、その DID が変更をコミットしました。しかし、それは私が期待したものではありませんでした。@Transactionalサービス メソッドを使用すると、トランザクションがコミットされ、セッションがフラッシュされてから返されることが保証されると思いました。一般に、Spring がこの管理をいつ行うかを決定することは知っていますが、メソッドの「作業単位」@Transactionalはそのメソッドだと思いました。

@Transactionalいずれにせよ、今は一般的にメソッドをテストする方法を理解しようとしています。

失敗しているjunitテストメソッドは次のとおりです。

セッションを手動でフラッシュすると、テストは成功します。@Transactionalただし、メソッドがセッションのコミットとフラッシュを処理することを期待していました。

updateUserSamePassword のサービス メソッドは次のとおりです。

DAO メソッドは次のとおりです。

SessionFactory は自動配線されています。

XML アプリケーション コンテキスト構成を使用しています。私は持っている：

と

サービスと dao クラスのコンポーネント スキャンもあります。私が言ったように、これは本番環境で機能しています。

そのメソッドの終わりまでにマークさ@Transactionalれたメソッドがある場合 (たとえば、ここでの更新メソッド)、Spring はセッションを強制的にコミットしてフラッシュするだろうと考えました。

いくつかのオプションしか表示されません。

1. これは一般的に機能していますが（単体テストではありません）、何かを誤って設定しました。推測はありますか？これをテストする方法についてのアイデアはありますか?

2. 単体テスト構成自体に関する何かが、アプリのように動作していません。

3. トランザクションとセッションはそのようには機能しません。私の唯一の推測は、その更新メソッドを呼び出した後、Spring がトランザクションおよび/またはセッションを開いたままにしているということです。そのため、Session オブジェクトでユーザーを手動で削除しても、それらの変更はまだコミットされていません。

これが予想される動作であるかどうかは誰でも確認できますか? @Transactionセッションでコミットとフラッシュを強制すべきではありませんか? そうでない場合、マークされたメソッドをどのようにテスト@Transactionalし、メソッドが実際にトランザクションで機能するかをテストしますか?

つまり、ここで単体テストをどのように書き直すべきですか?

他のアイデアはありますか？

私は DataSource と DataSourceTransactionManager スプリング Bean を使用し、それらを JobRepository Bean に配線しています。これらのいずれかがライフサイクルに対応していないか、Spring アプリケーションが閉じているときに接続を閉じるためのクローズ機能を持っているべきではありません。終了する前に DataSourceUtils.releaseConnection(...) を手動で呼び出さない限り、プロセスがハングします。ここで何か不足していますか？これを引き起こす可能性のあるコードに他のバグがありますか?

接続プールを使用する必要がありますか? 接続ライフサイクルを正しく管理するにはどうすればよいですか。

私のアプリケーションでは、純粋な JDBC を Guice と共に使用する必要があります。ただし、Guice はトランザクションを管理するための組み込みサポートを提供していません。guice-persist は、私が使用できない JPA に基づくサポートのみを提供します。

そこで、Guice と JDBC を使用してトランザクションを管理するための簡単なソリューションを実装しようとしました。最初のバージョンは次のとおりです。

1. TransactionHolder を使用して、スレッドごとにトランザクションを保存します。

   public class JdbcTransactionHolder {

   }

2. JDBC のトランザクション マネージャーを実装します。現在のところ、begin()、getTransaction()、commit()、および rollback() メソッドのみです。

   public class JdbcTransactionManager は TransactionManager を実装します {

   }

3. トランザクションが開始されている場合、トランザクション ホルダーから現在の接続を取得できる DataSource のラッパーを実装します。

   public class JdbcDataSource は DataSource を実装します {

   }

4. 次に、DataSourceProvider を作成して、Guice を使用して DataSource を任意の POJO に注入できるようにします。

   public class DataSourceProvider は Provider を実装します {

   /li>

5. 次に、TransactionalMethodInterceptor を実装して、Transactional アノテーションを使用してメソッドのトランザクションを管理します。

   public class TransactionalMethodInterceptor は MethodInterceptor を実装します {

   }

6. 最後に、Guice がインスタンスを注入できるようにすべてをまとめるコード:

   /li>

データソース プールには c3p0 を使用します。したがって、私のテストでは問題なく動作します。

関連する別の質問を見つけました：Guice、JDBC、およびデータベース接続の管理

しかし、これまでのところ、SpringFramework の何かを除いて、同様のアプローチは見つかりませんでした。しかし、Spring での実装でさえかなり複雑に思えます。

この解決策について何か提案があるかどうかを尋ねたいと思います。

ありがとう。

アプリケーションサーバー (JBoss EAP 6.1) のデバッグを開始すると問題が発生します。開始すると、コンソールで次の情報が DEBUG に表示されます。

また、DEBUG にある場合は、問題がどこにあるのかわからないため、問題を理解できます。何か提案はありますか？

Pyramid + Zope トランザクション マネージャー + SQLAlchemy + PostgreSQL を実行しています。場合によってはStaleDataError、Pyramid Web アプリケーションで、データベース内の 1 つの行を更新するという非常に些細なビューのエラーを見てきました。エラーは通常のビュー境界の外で発生し、再現できないため、デバッグが非常に困難です。

これは、壊れたデータベース接続またはトランザクション ライフサイクルと関係があるのではないかと思います。ただし、システムのデバッグを開始する方法がわからないため、これを引き起こす原因と、さらにこのようなエラーを特定する方法を尋ねています。

UPDATE statement on table 'xxx' expected to update 1 row(s); 0 were matched.