jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Hendriks <mhnd...@gmail.com>
Subject Re: the single-connection issue and prepared statements
Date Sun, 06 Dec 2009 18:18:58 GMT
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 <smartinez@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 <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