We're using 1.3.3. We took this build and source about November 2007. A new identical log message appears every 5 minutes, for ever until the appserver is bounced. It's still logging now, as ERROR. The database came back before 1am today.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dominique Pfister Sent: 15 January 2008 14:10 To: [email protected] Subject: Re: autcommit in DatabaseJournal.append 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-tp14140740p1 > 4839847.html Sent from the Jackrabbit - Users mailing list archive at > Nabble.com. > > E-MAIL DISCLAIMER The information in this e-mail and any attachment is confidential. It is intended only for the named recipient(s). If you are not a named recipient please notify the sender immediately and do not disclose the contents to another person or take copies. Although Axxia Systems has taken every reasonable precaution to ensure that any attachment to this e-mail has been checked for viruses,it is strongly recommended that you carry out your own virus check before opening any attachment, as we cannot accept liability for any damage sustained as a result of software virus infection. Axxia Systems reserves the right to monitor and record e-mails sent to axxia.com, and senders of such messages shall be taken to consent to this. Registered Office: Axxia House, Unit 4, The Pavilions, Ruscombe Business Park, Twyford, Berkshire, RG10 9NN. Registration Number: 3019229
