jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sten Martinez <smarti...@longfalcon.net>
Subject Re: the single-connection issue and prepared statements
Date Thu, 03 Dec 2009 16:32:36 GMT
Martijn,

any chance this will be back-ported to 1.6.x?

thanks,

sm

On Thu, Dec 3, 2009 at 12:21 AM, Martijn Hendriks <mhndrks@gmail.com> wrote:

> Hi Sten,
>
> This is a known problem (also see JCR-2226). A quite complete solution
> for issue JCR-1456 (database connection pooling) has yesterday made it
> into the trunk and is scheduled for the 2.0 release. This might very
> well solve your problem.
>
> Best regards,
>
> Martijn
>
> On Wed, Dec 2, 2009 at 8:22 PM, Sten Martinez <smartinez@longfalcon.net>
> wrote:
> > All,
> >
> > i have been working with jackrabbit 1.6.0 recently in a commercial
> > environment, and have run into some issues:
> > - the single connection doesn't play well with Oracle OCM. OCM closes the
> > connection, and the reconnect timout is entirely too long, especially
> with a
> > bursting traffic load. jackrabbit doesn't periodically make sure it's
> > connection is fresh, and the next group of hits will often cause a
> cascade
> > of waiting threads.
> > - the cluster journal's prepared statements are being collected or closed
> by
> > Oracle, even when the connection is still valid. this results in
> > unrecoverable errors, and the jackrabbit system gets out of sync.
> >
> > my question is: why does jackrabbit use the single connection anyway? do
> the
> > prepared statements even confer a significant performance benefit with
> > todays DBMS and hardware?
> >
> > i have had to make some customization to the 1.6.0 tag's code, to remove
> the
> > use of prepared statements entirely in the journal, and as an exercise i
> did
> > it in the rest of the system as well. also, i changed the executeStmt
> > methods (now called executeSQL) to  silently and easily get a new
> connection
> > if the old one died. this way, "transactional" operations that relied on
> the
> > constant connection will still work.
> >
> > is this on the roadmap for the 1.6.x branch, and if not, are you guys
> > interested in moving in this direction?
> >
> > thanks,
> >
> > sm
> >
>

Mime
View raw message