jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu ☀" <the.mindstorm.mailingl...@gmail.com>
Subject Re: ObjectPersistenceManager vs SimpleDbPersistenceManager
Date Wed, 08 Aug 2007 22:08:20 GMT
On 8/8/07, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> hi phillip
> On 8/7/07, Phillip Rhodes <spamsucks@rhoderunner.com> 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.

.w( the_mindstorm )p.

> >
> >
> >
> >
> > Thank you as always.
> > Phillip
> >
> >
> >

View raw message