We have a related issue wrt the connection used for the journal table. In some of our deployments the database (ms sqlserver) is taken down for a while overnight, I believe to backup. The rest of our application recovers from this when the database is available again, but the Jackrabbit cluster journalling doesn't seem to, there are continuous log entries appearing:
org.apache.jackrabbit.core.cluster.ClusterNode Periodic sync of journal failed: Unable to return record iterater. This would be another advantage of using the appserver connection pool (we use Jackrabbit in JBoss). Is there another way to recover from this without bouncing the appserver? Thanks Brett -----Original Message----- Hi Dominique, Thanks for the quick resolution. Just out of curiosity, what's the performance difference between the way jackrabbit has implemented sql execution vs calling... Connection conn = DataSource.getConnection(); PreparedStatement stmt = connection.prepareStatement(sqlString); ..... rs.close(); stmt.close(); connection.close(); every time to execute a sql statement? The thinking being that the above approach should perform just as quickly or quicker on the container because the driver or the container usually caches prepared statements and provides validated connections from a pool. We haven't yet done any testing ourselves to check if there's a difference. Thanks, Dainius -----Original Message----- From: Dominique Pfister [mailto:[EMAIL PROTECTED] Sent: December-04-07 11:09 AM To: [email protected] Subject: Re: autcommit in DatabaseJournal.append Hi Dainius, I could easily reproduce your scenario with a clustered setup and MySQL backend. Apparently, other backends are more tolerant when calling commit() on a connection that is already in auto-commit mode. I filed a JIRA issue for this: https://issues.apache.org/jira/browse/JCR-1254 and fixed it in the main trunk. Thank you very much for reporting! On 04/12/2007, dainius rygelis <[EMAIL PROTECTED]> wrote: > Hi Dominique, > > Yes, we're using 1.3.3. > > Two more questions... > Are the DatabaseJournal sql operations supposed in their own transaction? Yes. > Also, why the use of a single connection vs obtaining a new one when > needed from the connection pool supported datasource in the > DatabaseJournal, DbFileSystem/JNDIDatabaseFileSystem and > BundleDbPersistenceManager/JNDIDatabasePersistenceManager implementations? There are PreparedStatements inside these classes that one would have to prepare every time a connection is obtained from the pool. -- View this message in context: http://www.nabble.com/autcommit-in-DatabaseJournal.append-tp14140740p14839847.html Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
