hi alexandru On 8/9/07, Alexandru Popescu ☀ <[EMAIL PROTECTED]> wrote: > 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:
never questioned that, i just wanted to point out that fetching items individually from the persistence layer is not necessarily a 'problem', dependingon the choice of backend. jackrabbit's current default configuration (derby embedded) IMO copes very well with this approach. the PersistenceManager interface was originally designed with a simple HashMap-like model in mind, i.e. just put's and get's (think e.g. berkeley db). derby embedded comes pretty close to this performance wise when (mis)used as some sort of map. physical persistence should IMO ideally be as close as possible to the repository engine. using a remote database for jackrabbit is not what jackrabbit was originally designed for. maybe it was a mistake to make PeristenceManager a public interface in the first place. but that's a different story and just my personal opinion ;-) cheers stefan > > 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 > > > > > > > > > > > >
