jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: ObjectPersistenceManager vs SimpleDbPersistenceManager
Date Thu, 09 Aug 2007 11:54:28 GMT
hi alexandru

On 8/9/07, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com> wrote:
> 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:

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
> > >
> > >
> > >
> >
>
Mime
View raw message