jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Miro Walker" <miro.wal...@gmail.com>
Subject Re: JackRabbit maturity?- robustness, performance and scalability
Date Wed, 15 Nov 2006 10:06:29 GMT
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
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
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

Mime
View raw message