Thanks all, Now the question is
Why this kind of restriction is not hidden to us using a low level layer (physical) using a Strategy patter for each OS? Maybe i'm very lost on JCR :) Thanks again Luis On Thu, Oct 23, 2008 at 9:51 AM, Michael Wechner <[EMAIL PROTECTED]>wrote: > Jukka Zitting schrieb: > >> Hi, >> >> On Thu, Oct 23, 2008 at 9:10 AM, Michael Wechner >> <[EMAIL PROTECTED]> wrote: >> >> >>> Bertrand Delacretaz schrieb: >>> >>> >>>> Storing one million nodes should not be a problem, but you'll need to >>>> use a structure where no parent node has more than about 10k child >>>> nodes. >>>> >>>> >>> just being curious, but where does this number come from? >>> >>> >> >> It's a rough estimate I once made based on some ad-hoc experiments I >> made. The exact numbers of course vary per platform, but the problems >> typically start to manifest themselves somewhere within the 1k-100k >> range, with 10k being a good rule of thumb that I like to use when >> evaluating designs for content hierarchies. >> >> > > ok > >> >> >>> AFAIK the filesystems ext2 and ext3 (http://en.wikipedia.org/wiki/Ext3) >>> have >>> about 32'000 as limit, so I guess the question is how many files per >>> jackrabbit >>> node are needed? >>> >>> >> >> That depends on the persistence manager you use. None of the standard >> persistence managers hits the underlying file system limits in terms >> of child nodes, the issue is more about the size of the persisted >> parent node state. All the persistence managers currently store the >> names and identifiers of all the child nodes inside the serialized >> node state blob, so the more child node entries you have the slower it >> will be to read or write the parent node state. At some point you'll >> also start hitting things like BLOB size limits in persistence >> databases. >> >> > > ok > >> Caching typically takes away some of the pain related to large node >> states, but things like adding or removing a child node become >> increasingly slower the bigger the parent node is. >> >> > > thanks for this info > > Michael > >> BR, >> >> Jukka Zitting >> >> > > -- ------------------------------------------- Luis Alberto Gervaso Martin Java EE Architect & Instructor C/ Cuenca 4A, 2ºB Getafe (Madrid) SPAIN mobile: (+34) 627983344 [EMAIL PROTECTED]
