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: JackRabbit maturity?- robustness, performance and scalability
Date Wed, 15 Nov 2006 10:29:26 GMT
On 11/15/06, Miro Walker <miro.walker@gmail.com> wrote:
> Shaun,
> >  * versioning - our current model makes use of nt:hierarchyNode,
> > mix:referenceable, mix:lockable and mix:versionable. From your comments it
> > sounds like using mix:versionable will significantly reduce the reliability
> > of JackRabbit. Would you recommend NOT using mix:versionable therefore?
> >
> Well, it's a tricky question. We've been using mix:versionable and it
> does what it says on the tin, but we have had issues as described (see
> also JCR-566, JCR-630, JCR-631). All versioning will have a large
> overhead - your data volume will grow very quickly and you're adding a
> lot of complexity, so if versioning is optional in your application,
> it may be better not to use it. If you do have to include versioning,
> then using jackrabbit's support for it is still probably better than
> trying to roll your own, as these issues will certainly be resolved
> eventually.
> >  * persistence - we'd prefer to use the SimpleDbPersistenceManager with
> > MySql. Is this a popular/reliable combination?
> >
> The issue with the SimpleDBPM is that it stores all data as name-value
> pairs in the DB, which can be low-performance (writing a single node
> can require numerous insert statements). There are other approaches

i don't know what you mean by name-value pairs, however a node is persisted
using *one* insert/update statement.

> using DDL to dynamically generate tables in the DB that conform to
> nodetypes (so an entire node can be written with a single insert), but

i am still waiting for the proof that a normalized or node
type-reflecting schema
would be superior in terms of performance. i'd also be interested to learn how
residual child nodes/properties (e.g. nt:unstructered), non-typed
properties and
multi-valued properties would be handled.


> not currently committed to jackrabbit itself.
> >  * Fix "by hand" - Given that some persistence managers use binary
> > serialization, how do you go about correcting the integrity of the database?
> > The prospect scares me but its not uncommon with applications operating
> > ontop of schemas with complex referential integrity.
> >
> Well, it depends on the issue, but there are a couple of approaches -
> you can extract the blobs from the DB, reverse-engineer the underlying
> data, edit it and write it back. Alternatively you can use jackrabbit
> itself to edit the data. This would be done by, for example, editing
> the version history itself. This is normally read-only, so to do so
> requires bypassing some of the standard JCR API methods.
> >  * you mentioned Day CRX. We also installed this and we're initially
> > impressed with the polished package however since then we've found some
> > significant problems with the Content Explorer etc which sow the seed of
> > doubt that there are potentially bigger issues under the covers. It's
> > important for us to have a commercial alternative so I'd welcome any
> > comments/experiences on using Day versus JackRabbit - for example, is
> > mix:versionable viable with Day?
> >
> I'm happy to discuss this, but this is probably not the best forum -
> feel free to email me offline.
> Cheers,
> Miro

View raw message