From dev-return-26397-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Dec 02 19:22:55 2009 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 85441 invoked from network); 2 Dec 2009 19:22:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Dec 2009 19:22:55 -0000 Received: (qmail 20193 invoked by uid 500); 2 Dec 2009 19:22:55 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 20103 invoked by uid 500); 2 Dec 2009 19:22:55 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 20095 invoked by uid 99); 2 Dec 2009 19:22:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Dec 2009 19:22:55 +0000 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.78.25] (HELO ey-out-2122.google.com) (74.125.78.25) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Dec 2009 19:22:45 +0000 Received: by ey-out-2122.google.com with SMTP id 22so125162eye.1 for ; Wed, 02 Dec 2009 11:22:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.110.137 with SMTP id n9mr502915ebp.75.1259781744242; Wed, 02 Dec 2009 11:22:24 -0800 (PST) X-Originating-IP: [171.71.86.220] Date: Wed, 2 Dec 2009 11:22:24 -0800 Message-ID: <6a652e790912021122p4af21647r112b45fcbee3cffe@mail.gmail.com> Subject: the single-connection issue and prepared statements From: Sten Martinez To: dev@jackrabbit.apache.org Content-Type: multipart/alternative; boundary=00504502c4695c31de0479c3cbec X-Virus-Checked: Checked by ClamAV on apache.org --00504502c4695c31de0479c3cbec Content-Type: text/plain; charset=ISO-8859-1 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 --00504502c4695c31de0479c3cbec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

i have been working with jackrabbit 1.6.0 recently in a commerc= ial environment, and have run into some issues:
- the single connection = doesn't play well with Oracle OCM. OCM closes the connection, and the r= econnect timout is entirely too long, especially with a bursting traffic lo= ad. jackrabbit doesn't periodically make sure it's connection is fr= esh, and the next group of hits will often cause a cascade of waiting threa= ds.
- the cluster journal's prepared statements are being collected or clos= ed by Oracle, even when the connection is still valid. this results in unre= coverable errors, and the jackrabbit system gets out of sync.

my que= stion is: why does jackrabbit use the single connection anyway? do the prep= ared statements even confer a significant performance benefit with todays D= BMS and hardware?

i have had to make some customization to the 1.6.0 tag's code, to r= emove the use of prepared statements entirely in the journal, and as an exe= rcise i did it in the rest of the system as well. also, i changed the execu= teStmt methods (now called executeSQL) to=A0 silently and easily get a new = connection if the old one died. this way, "transactional" operati= ons 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 i= nterested in moving in this direction?

thanks,

sm
--00504502c4695c31de0479c3cbec--