Hi, for quite some time, the database journal closes a connection if an error occurs and should therefore recover gracefully from this situation. What version of jackrabbit are you using?
Kind regards Dominique On 15/01/2008, Brett Connor <[EMAIL PROTECTED]> wrote: > > 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. > >
