Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 1292 invoked from network); 19 Apr 2006 10:51:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Apr 2006 10:51:23 -0000 Received: (qmail 43979 invoked by uid 500); 19 Apr 2006 10:51:15 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 43949 invoked by uid 500); 19 Apr 2006 10:51:15 -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 43940 invoked by uid 99); 19 Apr 2006 10:51:15 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Apr 2006 03:51:15 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of stefan.guggisberg@gmail.com designates 64.233.162.199 as permitted sender) Received: from [64.233.162.199] (HELO nz-out-0102.google.com) (64.233.162.199) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Apr 2006 03:51:14 -0700 Received: by nz-out-0102.google.com with SMTP id z3so929378nzf for ; Wed, 19 Apr 2006 03:50:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nbHhVLt667M6sGH5jCzp4RsnmoJHkiswidfz+CIOlsgaWRVfsXq3Y1r9AQRuIjO9WnmdF2Ew7MuIZtSX8Pr9PJQUcpXJgZIwGf43Z3E+8hR37KyWg5WDtbgnyrfMOBkwP7V1KXIAc6/OaTRfSp+qfaFqD52hSwQQhUoX5S+t+18= Received: by 10.64.88.11 with SMTP id l11mr73130qbb; Wed, 19 Apr 2006 03:50:54 -0700 (PDT) Received: by 10.64.47.5 with HTTP; Wed, 19 Apr 2006 03:50:54 -0700 (PDT) Message-ID: <90a8d1c00604190350l89ffd0duc2d115752aed1cff@mail.gmail.com> Date: Wed, 19 Apr 2006 12:50:54 +0200 From: "Stefan Guggisberg" To: dev@jackrabbit.apache.org Subject: Re: SQLException "Data too long" using SimpleDbPersistenceManager/MySQL In-Reply-To: <4445F249.3070706@nuxeo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200604181754.k3IHsmft013482@post.webmailer.de> <90a8d1c00604190103h1c4842bbm239ca6f7a070329f@mail.gmail.com> <4445F249.3070706@nuxeo.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N hi florent On 4/19/06, Florent Guillaume wrote: > Stefan Guggisberg wrote: > > btw: you should in general try to avoid flat hierarchies in jackrabbit > > as they come at a certain performance cost. > > Hi Stefan, > > Could you expand a bit on that? Aren't there any BTree-like structures us= ed > to store children on unordered nodes? Does this depend on the backend > storage? Are any linear searches attempted in some places? the NodeState object, jackrabbit's internal representation of a jcr Node, maintains the collection of child node entries (name, subscript, uuid). hash maps are used for accessing accessing an entry by name or uuid. have a look at the NodeState and NodeState #ChildNodeEntries classes in the o.a.j.core.state package. this should answer all your questions. 'fat' nodes take longer to load, copy and store. they obviously also use up more memory and therefore may affect gc performance. manipulating a large collection of same-name sibling entries (remove/insert) may take more time than performing the same operation on a smaller collection. cheers stefan > > Thanks, > Florent > > -- > Florent Guillaume, Nuxeo (Paris, France) Director of R&D > +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com >