On 8/8/07, Stefan Guggisberg <[EMAIL PROTECTED]> wrote: > hi phillip > > On 8/7/07, Phillip Rhodes <[EMAIL PROTECTED]> wrote: > > Hello everyone, > > > > I did some debugging for my performance problems with > > SimpleDbPersistenceManager. > > I ran SimpleDbPersistenceManager with jdbclogger and found that Jackrabbit > > will issue 2+ sql queries for each node as I iterator through the > > NodeIterator. This does not scale well for me. > > please note that items read from the persistence layer are cached. > those items will be delivered from cache on subsequent reads > (unless they've been evicted in the mean time of course). > > > > > I am considering switching my workspace to use the ObjectPersistenceManager > > . I understand it is not reliable as the SimpleDbPersistenceManager, but > > since I won't be issuing 400+ database queries, I hope the performance for > > my application will improve. > > what db are you using? i doubt that you'll see a dramatic performance > improvement > when compared to using embedded derby. furthermore, derby supports > transactions. > > > > > Am I risking the entire repository becoming corrupt, or just a few nodes > > becoming corrupt? I don't mind a few nodes becoming corrupt, but if the > > entire repo can become corrupt if the repository is killed, I would > > appreciate knowing this! > > well, if e.g. the root node or something like /myapp:products gets > corrupt you're in trouble. > it's like a dos file system, when your FAT gets corrupt you may end up > with a pretty mess. > > personally i wouldn't recommend using the file system-based pm's, > certainly not for production systems. > > cheers > stefan >
Stefan I do agree with all your comments above. Howver, I find Phillip's observation extremely valuable: 1/ SimpleDbPersistenceManager: suffers from the N+1 select problem (each property read will generate an additional select) 2/ BundlePMs are solving the above problem for the property access (I must confess that I'm stucked with an old version so I am not very familiar with the BundledPMs yet). But, we can have (or at least think) about an even better/customizable approach for fetching children. This problem has been addressed by the top ORM frameworks out there: fetching strategy. When fetching the parent-child related information, this can be customized to work with N+1 (which I think is the way BundledPM works for fetching child nodes) or with FETCH_JOIN. bests, ./alex -- .w( the_mindstorm )p. > > > > > > > > > > Thank you as always. > > Phillip > > > > > > >
