You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Sten Martinez <sm...@longfalcon.net> on 2009/12/02 20:22:24 UTC
the single-connection issue and prepared statements
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
Re: the single-connection issue and prepared statements
Posted by Martijn Hendriks <mh...@gmail.com>.
Hi Sten,
Normally we only backport bug fixes to the release branches, so probably not.
Best regards,
Martijn
On Thu, Dec 3, 2009 at 5:32 PM, Sten Martinez <sm...@longfalcon.net> wrote:
> 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 <mh...@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 <sm...@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
>> >
>
>
Re: the single-connection issue and prepared statements
Posted by Sten Martinez <sm...@longfalcon.net>.
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 <mh...@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 <sm...@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
> >
>
Re: the single-connection issue and prepared statements
Posted by Martijn Hendriks <mh...@gmail.com>.
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 <sm...@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
>