RE: autcommit in DatabaseJournal.append

[Brett Connor <co...@axxia.com>]

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:dominique.pfister@day.com] 
Sent: December-04-07 11:09 AM
To: users@jackrabbit.apache.org
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 <da...@pitchpointsolutions.com>
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.

Re: autcommit in DatabaseJournal.append

[Dominique Pfister <do...@day.com>]

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 <co...@axxia.com> 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:dominique.pfister@day.com]
> Sent: December-04-07 11:09 AM
> To: users@jackrabbit.apache.org
> 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 <da...@pitchpointsolutions.com>
> 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.
>
>