問題タブ [persistence-manager]

私はこのようないくつかのコードを持っています:

上記の pm を使用して、複数のオブジェクトを処理してから閉じても問題ないのでしょうか。または、各オブジェクトを処理するために pm を取得して閉じる必要がありますか?

データストアに何かを保存しようとすると、このエラーが発生します。検索しようとしましたが、何も得られませんでした。これは私がデータストアに保存しているコードです：

これに関するどんな種類の情報もありがたいです！

編集：スタックトレースの追加：

com.sample.dbops.DBManager.saveStudent（DBManager.java:18）at org.apache.jsp.index_jsp._jspService（index_jsp.java:64）at org.apache.jasper.runtime.HttpJspBase.service（HttpJspBase.java ：94）javax.servlet.http.HttpServlet.service（HttpServlet.java:806）at org.apache.jasper.servlet.JspServletWrapper.service（JspServletWrapper.java:324）atorg.apache.jasper.servlet.JspServlet。 serviceJspFile（JspServlet.java:292）at org.apache.jasper.servlet.JspServlet.service（JspServlet.java:236）at com.google.appengine.tools.development.PrivilegedJspServlet.access $ 101（PrivilegedJspServlet.java:23）at com.google.appengine.tools.development.PrivilegedJspServlet $ 2.run（PrivilegedJspServlet.java:59）at java.security.AccessController.doPrivileged（Native Method）atcom.google.appengine.tools.development.PrivilegedJspServlet。service（PrivilegedJspServlet.java:57）at javax.servlet.http.HttpServlet.service（HttpServlet.java:806）at org.mortbay.jetty.servlet.ServletHolder.handle（ServletHolder.java:487）at org.mortbay.jetty .servlet.ServletHandler.handle（ServletHandler.java:362）at org.mortbay.jetty.security.SecurityHandler.handle（SecurityHandler.java:216）at org.mortbay.jetty.servlet.SessionHandler.handle（SessionHandler.java:181 ）org.mortbay.jetty.handler.ContextHandler.handle（ContextHandler.java:712）at org.mortbay.jetty.webapp.WebAppContext.handle（WebAppContext.java:405）atcom.google.apphosting.utils.jetty。 DevAppEngineWebAppContext.handle（DevAppEngineWebAppContext.java:54）at org.mortbay.jetty.servlet.Dispatcher.forward（Dispatcher.java:268）at org.mortbay.jetty.servlet.Dispatcher.forward（Dispatcher.java:126）at com 。グーグル。appengine.tools.development.StaticFileUtils.serveWelcomeFileAsForward（StaticFileUtils.java:80）at com.google.appengine.tools.development.LocalResourceFileServlet.maybeServeWelcomeFile（LocalResourceFileServlet.java:251）atcom.google.appengine.tools.development.LocalResourceFileServlet。 doGet（LocalResourceFileServlet.java:117）at javax.servlet.http.HttpServlet.service（HttpServlet.java:693）at javax.servlet.http.HttpServlet.service（HttpServlet.java:806）at org.mortbay.jetty.servlet .ServletHolder.handle（ServletHolder.java:487）at org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter（ServletHandler.java:1093）at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter（TransactionCleanupFilter.java ：43）org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter（ServletHandler.java：1084）com.google.appengine.tools.development.StaticFileFilter.doFilter（StaticFileFilter.java:124）at org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter（ServletHandler.java:1084）at org.mortbay.jetty .servlet.ServletHandler.handle（ServletHandler.java:360）at org.mortbay.jetty.security.SecurityHandler.handle（SecurityHandler.java:216）at org.mortbay.jetty.servlet.SessionHandler.handle（SessionHandler.java:181 ）org.mortbay.jetty.handler.ContextHandler.handle（ContextHandler.java:712）at org.mortbay.jetty.webapp.WebAppContext.handle（WebAppContext.java:405）atcom.google.apphosting.utils.jetty。 org.mortbay.jetty.handler.HandlerWrapper.handle（HandlerWrapper.java:139）のDevAppEngineWebAppContext.handle（DevAppEngineWebAppContext.java:54）（com.google.appengine.tools.development）。JettyContainerService $ ApiProxyHandler.handle（JettyContainerService.java:313）at org.mortbay.jetty.handler.HandlerWrapper.handle（HandlerWrapper.java:139）at org.mortbay.jetty.Server.handle（Server.java:313）at org .mortbay.jetty.HttpConnection.handleRequest（HttpConnection.java:506）at org.mortbay.jetty.HttpConnection $ RequestHandler.headerComplete（HttpConnection.java:830）at org.mortbay.jetty.HttpParser.parseNext（HttpParser.java:514 ）org.mortbay.jetty.HttpParser.parseAvailable（HttpParser.java:211）at org.mortbay.jetty.HttpConnection.handle（HttpConnection.java:381）at org.mortbay.io.nio.SelectChannelEndPoint.run（SelectChannelEndPoint。 java：396）org.mortbay.thread.BoundedThreadPool $ PoolThread.run（BoundedThreadPool.java:442）HandlerWrapper.handle（HandlerWrapper.java:139）at org.mortbay.jetty.Server.handle（Server.java:313）at org.mortbay.jetty.HttpConnection.handleRequest（HttpConnection.java:506）at org.mortbay.jetty .HttpConnection $ RequestHandler.headerComplete（HttpConnection.java:830）at org.mortbay.jetty.HttpParser.parseNext（HttpParser.java:514）at org.mortbay.jetty.HttpParser.parseAvailable（HttpParser.java:211）atorg。 mortbay.jetty.HttpConnection.handle（HttpConnection.java:381）at org.mortbay.io.nio.SelectChannelEndPoint.run（SelectChannelEndPoint.java:396）at org.mortbay.thread.BoundedThreadPool $ PoolThread.run（BoundedThreadPool.java： 442）HandlerWrapper.handle（HandlerWrapper.java:139）at org.mortbay.jetty.Server.handle（Server.java:313）at org.mortbay.jetty.HttpConnection.handleRequest（HttpConnection.java:506）at org.mortbay.jetty .HttpConnection $ RequestHandler.headerComplete（HttpConnection.java:830）at org.mortbay.jetty.HttpParser.parseNext（HttpParser.java:514）at org.mortbay.jetty.HttpParser.parseAvailable（HttpParser.java:211）atorg。 mortbay.jetty.HttpConnection.handle（HttpConnection.java:381）at org.mortbay.io.nio.SelectChannelEndPoint.run（SelectChannelEndPoint.java:396）at org.mortbay.thread.BoundedThreadPool $ PoolThread.run（BoundedThreadPool.java： 442）HttpConnection $ RequestHandler.headerComplete（HttpConnection.java:830）at org.mortbay.jetty.HttpParser.parseNext（HttpParser.java:514）at org.mortbay.jetty.HttpParser.parseAvailable（HttpParser.java:211）at org.mortbay .jetty.HttpConnection.handle（HttpConnection.java:381）at org.mortbay.io.nio.SelectChannelEndPoint.run（SelectChannelEndPoint.java:396）at org.mortbay.thread.BoundedThreadPool $ PoolThread.run（BoundedThreadPool.java:442 ）。HttpConnection $ RequestHandler.headerComplete（HttpConnection.java:830）at org.mortbay.jetty.HttpParser.parseNext（HttpParser.java:514）at org.mortbay.jetty.HttpParser.parseAvailable（HttpParser.java:211）at org.mortbay .jetty.HttpConnection.handle（HttpConnection.java:381）at org.mortbay.io.nio.SelectChannelEndPoint.run（SelectChannelEndPoint.java:396）at org.mortbay.thread.BoundedThreadPool $ PoolThread.run（BoundedThreadPool.java:442 ）。BoundedThreadPool $ PoolThread.run（BoundedThreadPool.java:442）BoundedThreadPool $ PoolThread.run（BoundedThreadPool.java:442）

私のJavaスキルは少し錆びていて、GoogleAppEngine環境のサーブレットから呼び出されたPersistenceManagerのOpenSessionInViewパターンをどのように実装できるのか疑問に思っています。

PersistenceManagerFactoryを処理するシングルトンがいくつかありますが、サーブレット呼び出しごとに「新しい」PersistenceManagerを取得するにはどうすればよいですか。

ビジネスクラスが同じPersistenceManagerを使用するリポジトリにアクセスし、常に（1つのサーブレットリクエスト内で）アクセスできるようにしたい。

今のところ、サーブレット要求ごとに、シングルトンへの最初の呼び出しが行われたときに新しいPersistenceManagerを初期化する方法を理解できません...

助けてくれてありがとう。

JDO 永続マネージャ (以下、PM) の作成/使用方法について 2 つの質問があります。

Java Web アプリケーションで、10 個のエンティティがあり、論理的に 2 つのグループにグループ化できるとします (たとえば、5 つのユーザー関連エンティティと 5 つのビジネス関連エンティティ)。

1. これら 2 つのグループを管理するには 2 つの異なる PM が必要ですか、それとも 1 つの PM だけで十分ですか?
2. 初期化に関して、PM のシングルトン インスタンス (特定の時点でアプリを使用しているすべてのユーザーによって共有される) を使用するか、セッションごとに PM を作成する必要がありますか?

mod_jk を実行する共通の Web サーバーを共有する Tomcat サーバーのクラスターがあります。現在、スティッキー セッションを使用してセッション処理を処理していますが、JDBC セッション共有に移行したいと考えています。これに対処するための適切なリソースまたは段階的な解決策を誰かが持っていますか?

この質問がstackoverflow、serverfault、またはDBAを対象としているかどうかはわかりませんでしたが、ここにあります. :)

編集：

私の質問の内容は紛らわしいに違いないと思います。私が参照しているセッションは、データベースへの接続ではなく、ユーザー セッション (JSESSIONID) です。私がやりたいことは、データベースを使用してユーザー セッションを処理し、クラスター内の 1 つのサーバーがダウンしたときに、ユーザーが別のサーバーにシームレスに移行できるようにすることです。現在、サーバーでエラーが発生すると、ユーザーはログアウトされます。

プロジェクトに使用する永続性マネージャーのタイプを決定しようとしています。私はpersistenceManagersに関するこのwikiエントリを読みました。

まず第一に、JCR-2802（すべての非バンドルPMは非推奨）のため、

そして、それらすべてのInMem、Object、XmlPersistenceManagersは非推奨になりました。（InMemPMが非推奨になっている間もMemoryFileSystemはOKですか？）

これを見ると、BundleFsPersistenceManagerはLocalFileSystemを使用してファイルを永続化し（コンテンツがファイルに保存される方法を説明するwikiエントリはありますか？-nt：fileなどのさまざまなタイプのノードプロパティのように）、BundleDbPersistenceManagerはDbFileSystemを使用しますまったく同じファイルをDBMSに保存するには？そうしないと、Luceneのインデックス作成と全文検索ができません。

その理由は、システムのクラスタリングと分散性、および原子性です...そうでなければ、データベースの実装は冗長になりますよね？このように人々はより多くの選択肢を持っています。

JBoss の起動時に、JDBC 接続 (DefaultDS) に依存する Persistence Manager があります。JDBC 接続は、実際にデータベースに接続できるかどうかに関係なく正常に開始されるため、Persistence Manager の開始時に接続があると認識されます。その後、データベースに接続できず、起動しないため、爆発します。これにより、DestinationManager が起動しなくなり、あらゆる種類の頭痛の種になります。

JDBC 接続が実際にデータベースに接続できない限り、JDBC 接続に依存する MBean を開始しないようにする方法はありますか? 別の方法として、JDBC 接続を、データベースに接続できるときにのみアクティブな MBean に依存させる方法はありますか?

tl;dr; 必要なのは、MBeans/DestinationManager が起動前にデータベース (DefaultDS) が使用可能になるまで待機することだけです。

環境についてさらに情報が必要な場合は、コメントしてください。

• JBoss バージョン 4.2.3

• データベース: MSQL

複数のユーザーがいます。同時実行を防ぐために、次のように書きます。

これは私のために働いた。ただし、何かを永続化してから、同じトランザクションでこのコードを呼び出すと、エラーが発生します。

エンティティを永続化すると、トランザクションが完了するまでデータベース コンテキストは影響を受けません。そのため、更新すると、データベースでエンティティを見つけようとするため、エラーが発生します。解決策はありますか？2回に分けてのお取引はできません。並行性も考慮する必要があります。私に何ができる？

これを使用して、GAE（java）の300,000エンティティを削除しようとしています。

1日あたりの書き込み操作は50000に制限されています（無料の割り当て）。私は素朴に6〜7日でそれを行うべきだと思いましたが、1回の呼び出しで1日の割り当ての1/5が使用されているようです。

->データストア書き込み操作 21％0.05MillionOpsの0.01

10 000の書き込み操作、なぜ750ではないのですか？

インデックスと関係がありますか？

MySQL にセッションを保存するために JDBCStore を使用しています。正常に動作していますが、デフォルトの構成オプションはデータベース プール (JDBC JNDI リソース経由で利用可能) をサポートしていないようです。

JDBC Persistence Manager に JNDI JDBC リソースを使用して、セッション データを永続化または取得する必要があるたびにコンテナが新しい接続を作成する必要がないようにすることはできますか?

乾杯、スティーブ