問題タブ [guice-persist]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
1356 参照

jpa - 複数の持続性ユニットを持つ Guice JpaRepositoryModule

次のように、persistence.xml で 2 つの PU を宣言しました。

JpaPersistenceModule を次のように構成します。

リポジトリ クラスをバインドします。

リポジトリ クラスは @Transacional で注釈が付けられ、どの PU であるかを宣言します。

「anotherJpaUnit」にマッピングされたエンティティは1つだけで、次のように宣言されています。

しかし、アプリケーションを起動すると、Guice の初期化でエラーがスローされます。

テーブル「_user」は「anotherJpaUnit」にしか存在しないのに、「MyJpaUnit」とバインドしようとするのはなぜですか? ここで何が間違っているのかわかりません。複数の PU が動作する JpaRepositoryModule の例はありますか?

0 投票する
1 に答える
168 参照

guice - トランザクション フックを提供するための Guice JPA サポートの拡張

トランザクションにコミット後のフックが必要であることがわかりました。イベント ストアを使用しており、トランザクションがコミットされるまでイベントが発行されないようにする必要があります。これは、イベント ハンドラーが前のトランザクションからのデータを必要とする可能性があるためです。

JPAモジュールでGuiceを使用してすべてを接続しています。JpaLocalTxnInterceptorguice-persist モジュールから変更することで非常に簡単にフックを追加できると思います。使用@Transactionalをやめて手動で行うこともできますが、このボイラープレートを非表示にすることをお勧めします。より良い解決策はありますか?

0 投票する
1 に答える
2197 参照

java - c3p0 接続が期限切れです

c3p0 0.9.2.1、GWT 2.6.0、SQLServer 2012 を使用しています。

c3p0 から断続的な stackTrace を取得しています

つまり、指定したタイムアウト内に接続が完了していないことがわかります

これがどのように可能であるかを理解できません。私のコードは非常に単純です...

起動時に、25 個のスレッドが起動し、それぞれが getSomeQueueData() を呼び出します。約 1/10 の確率で失敗します。デバッグ出力を確認すると、予想どおり数秒以内にすべてのスレッドが正常にメソッドに出入りしたことがわかりました。明確にするために、 @Transactional は春ではなく装いです。

---編集--- 私はこの問題を調査するのに何時間も費やしましたが、さらに不可解になるだけです....

また、c3p0 を 0.9.5 に更新しました。

@Transactional は、何らかの理由で不安定なようです。たまに呼ばれません。DAO を通過するすべてのメソッドのスタック トレースを調べると、インターセプターの処理がスキップされていることがよくあります??.

私の DAO には getSession() メソッドがあり、100ms の任意のスリープを追加すると、ほぼすべての stackTrace が注釈がスキップされたことを示します。

さらに、これらの設定により、ほぼ毎回問題が発生します

...これらの設定により、問題が発生することはほとんどありません

また、c3p0 を完全に削除すると、テストで明らかになった限り、問題が完全に解決するようです。

finally の使用は、リフレクションが偽装で使用された場合に注意する必要があることを読んだことがあり、それを避けるように注意してきました。症状が奇妙すぎて絞り込めません。guice がクラスを正しくバインドしていないように見える場合もあれば、c3p0 エラーのように見える場合もあります。

ああ、com.google.inject.persist.Transactional を使用していることを確認しました。

0 投票する
1 に答える
706 参照

caching - EclipseLink + JPA Guice の永続化と再デプロイ

私はEclipseLink + JPA Guice Persistに基づくインフラストラクチャを持っています

アプリケーションを再デプロイすると、常にエンティティのキ​​ャッシングでキャッシングの問題が発生し、サーバー (Oracle Weblogic 11g) を再起動する必要があります。 ?id=326552 でも、もしかしたらバグじゃないかも¿?¿ ...

私は次のように問題を解決することができました:

もともと私は GuiceModule ですべてを一元化しました:

1.モジュール JPAPersist を作成する

2.persistenceService.start()を呼び出すInitializerクラスのバインディング

すべて正常に動作します....しかし、私が言ったように、再展開するとインスタンスがキャッシュされたままになります

どうすれば解決できますか?

  1. メソッド JPAInitializer を変更しました

    public static class JPAInitializer {

    /li>
  2. サービスを停止するメソッド stop() を作成しました..しかし、WTF! 注入された永続サービスを静的変数に保存することを余儀なくされました:((

  3. エントリポイントである guice/listener フィルターから、アプリケーションがアンデプロイされたときに停止を呼び出します (onContextDestroyed)

    public void contextDestroyed(ServletContextEvent servletContextEvent) { JPAInitializer.stop();
    }

今、再デプロイしてもキャッシュの問題や問題はなく、サーバーを再起動する必要はありません

このように動作しますが、静的インスタンス PesistenceService. を作成しても問題ないかどうかわからないので、停止を呼び出す別の方法を見つけようとしています.....

なにか提案を?

0 投票する
1 に答える
165 参照

hibernate - Warp-Persist で Guice をアップグレードする依存関係の問題

warp-servlet および warp-persist で Guice 1.0 を使用するアプリケーションがあり、Guice 2 または 3 にアップグレードしたいと考えています。

warp-persist を新しい Guice で動作させるか、Guice-persist をストレート Hibernate で動作させる簡単な方法 (ドロップイン置換にできるだけ近い) を知っている人はいますか?

  • Warp-persist には warp-servlet が必要です
  • Warp-servlet と warp-persist は Guice 1.0 のみをサポートします
  • Guice-persist は warp-persist に取って代わるように見えますが、JPA のみをサポートしていますが、Hibernate を直接使用しています (JPA への移植を自明ではなくする基準ベースのコードの重要な遺産があります)。
  • Guice-persist は、JPA 以外のデータ アクセスをサポートする方法もあると主張していますが、これに関するドキュメントはないようです。
  • Warp-persist は Hibernate 4 をサポートしていないようです。そのため、Hibernate もアップグレードできません。
0 投票する
1 に答える
3215 参照

java - ガイダンスプロバイダー対EntityManager

永続性とサーブレットの Guice 拡張機能を使用して、Jetty で Guice と JPA を使用して単純な webapp を動作させようとしていました。

私はこの Service 実装クラスを書きました:

}

そして、これは私のサーブレットです(@Singletonで注釈が付けられています):

これを実行すると機能し、名前がクライアントに送信されますが、ログを見ると、挿入用に生成された DML がなく、postgresql から選択しても結果が返されないことがわかります。 t 本当に固執しました。

コードをデバッグしたところ、 がJpaLocalTxnInterceptor呼び出されていることがわかりましたtxn.commit()

次に、変更を加えて、代わりにPersonServiceImpl使用したところ、期待どおりに機能しました。その理由はよくわかりません。おそらく、Provider の背後にある考え方をよく理解していないためです。Guice wiki ページには、次のように書かれています。Provider<EntityManager>EntityManager

MyService を @Singleton にする場合は、代わりに Provider を注入する必要があることに注意してください。

ただし、私の PersonServiceImpl は @Singleton ではないため、なぜそれが適用されるのかわかりません。おそらくサーブレットが原因でしょうか?

これを明確にしていただければ幸いです。

0 投票する
1 に答える
4013 参照

java - 実行時に HikariCP + Hibernate + GuicePersist(JPA) を構成する

GuicePersist、Hibernate、および HikariCP を使用して Postgres DB と通信する Java8 デスクトップ アプリがあります。この META-INF/persistence.xml を使用して、アプリが DB にデータを送受信することに成功しました。

トリッキーな部分は、実行時に Guice JpaPersistModule を構成することです。私が知る限り、次のように Map オブジェクトのプロパティを設定することで、META-INF/persistence.xml ファイルのプロパティをオーバーライドできるはずです。

次に jpaModule.properties(properties) を作成し、これをすべて GuicePersist に渡します。

Map でプロパティ名のさまざまな組み合わせを試しましたが、今のところうまくいきません。このトピックに関する pgsimpledatasource のドキュメントと hikariCP のドキュメントも参照しましたが、まだデータソースのプロパティが設定されていません。

誰か助けてくれませんか?本当にありがとう。

0 投票する
2 に答える
3627 参照

hibernate - 休止状態で切断されたデータベース接続から回復する

切断されたデータベース接続からの回復に問題があります。私のテスト ケースでは、次のライブラリを使用します。
guice-persist 4.0
Hibernate コア 4.3.1
HikariCP-java6-2.3.9 (接続プール)。

私のテストは、各読み取りの間に小さなスリープを入れてループで単純な読み取りを実行します。

Dao はこのように entityManager を取得します

guice モジュールはこのようにバインドされています

私のpersistence.xmlは、トランザクションタイプを「RESOURCE-LOCAL」と定義しています。

光の設定がいくつかありますが、これらが関連しているかどうかはわかりません

テストが読み取りをループしている間、タスク マネージャーからサービスを停止して SQLServer 接続を切断します。その時点でループが simplRead() メソッドになかった場合は、次に試行された読み取りでエラーを適切に処理し、サービスが再び開始されたときに再接続します。ただし、サービスが停止したときに simpleRead() メソッドにあった場合、サービスは失敗し、回復することはありません。最初の失敗は次のように報告されます


org.hibernate.TransactionException: JDBC begin transaction failed: javax.persistence.PersistenceException: org.hibernate.TransactionException: JDBC begin transaction failed: at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1771) at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:64) at com.google.inject.persist.jpa.JpaLocalTxnInterceptor.invoke(JpaLocalTxnInterceptor.java:66) at net.impro.portal.server.model.dao.TestConnectionStuff.testConnectionBroken(TestConnectionStuff.java:40) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) at org.testng.TestRunner.privateRun(TestRunner.java:767) at org.testng.TestRunner.run(TestRunner.java:617) at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) at org.testng.SuiteRunner.run(SuiteRunner.java:240) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1197) at org.testng.TestNG.runSuitesLocally(TestNG.java:1122) at org.testng.TestNG.run(TestNG.java:1030) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111) at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204) at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175) Caused by: org.hibernate.TransactionException: JDBC begin transaction failed: at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:76) at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:162) at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1431) at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:61) ... 26 more Caused by: java.sql.SQLException: I/O Error: Connection reset by peer: socket write error at net.sourceforge.jtds.jdbc.TdsCore.executeSQL(TdsCore.java:1059) at net.sourceforge.jtds.jdbc.TdsCore.submitSQL(TdsCore.java:905) at net.sourceforge.jtds.jdbc.JtdsConnection.setAutoCommit(JtdsConnection.java:2291) at com.zaxxer.hikari.proxy.ConnectionProxy.setAutoCommit(ConnectionProxy.java:334) at com.zaxxer.hikari.proxy.ConnectionJavassistProxy.setAutoCommit(ConnectionJavassistProxy.java) at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:72) ... 29 more Caused by: java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(Unknown Source) at java.net.SocketOutputStream.write(Unknown Source) at java.io.DataOutputStream.write(Unknown Source) at net.sourceforge.jtds.jdbc.SharedSocket.sendNetPacket(SharedSocket.java:717) at net.sourceforge.jtds.jdbc.RequestStream.putPacket(RequestStream.java:570) at net.sourceforge.jtds.jdbc.RequestStream.flush(RequestStream.java:518) at net.sourceforge.jtds.jdbc.TdsCore.executeSQL(TdsCore.java:1046) ... 34 more ...

そして、それが適切にクリーンアップされないため、後続のリクエストは次のように失敗します

この問題の原因となっているレイヤーを特定するのは簡単ではありません。私が読んだことから、接続プールは壊れた接続をテストしてクリーンアップする必要がありますが、スレッドローカルオブジェクトに関連付けられた壊れた EntityManager 参照を永久に保持する guice-persist が疑われます。もちろん、それは私がそれらを使用する方法でもあるかもしれません.

編集

さらに調査した結果、各テスト読み取りの間に 1000 ミリ秒以上待機すると、コードが期待どおりに動作することに気付きました。以下の StackTrace を取得し、SQLServer サービスを復元すると、問題なく再接続されます。1000 ミリ秒未満の場合、元の投稿で上記のエラーが表示されます。休止状態は IO/Error を同じ方法で処理しないようで、接続は永久に壊れた状態のままです。

0 投票する
1 に答える
282 参照

java - Guice を使用した Restlet の実装

Guiceの導入により、Java 開発は大きく前進しました。私のプロジェクトは、持続性についてWarp-persistとその後継のGuicePersistに大きく依存しています。

しかし、Guice と Restlet の使用には不一致があるようです。@Injectサーブレット レベルからのセッション ファクトリと永続化ファクトリに対してのみ可能なようです。トランザクション処理のために、 @TransactionalUnitOfWorkなどの永続ServerResources化を可能にする Restlet を作成するために Guice が必要です。@Inject

  • Restlet のロードマップで Guice に変更はありますか?

  • Restlet で Guice を使用するためのベスト プラクティスはありますか?

よろしく、

ローランド・ボイカー

0 投票する
0 に答える
580 参照

jpa - 実行時構成で JpaPersistModule を guice

とデータソースを共有する必要がありますJpaPersistModule。このデータソースは、guice インジェクターによって提供されます。

構成フェーズでモジュールをビルドする必要がある問題ですが、データソースは実行時にのみ使用できます。

現在、次のコードがあります。

確認したところ、jpa プロパティ マップは参照によってどこにでも挿入されているように見えるため、ランタイムの変更が表示されるはずですが、これが将来変更された場合はどうなりますか?

このような競合を解決する正しい方法は何ですか?