jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Considering Jackrabbit
Date Mon, 18 Jul 2005 12:44:35 GMT
On 7/18/05, Serge Huber <shuber2@jahia.com> wrote:
> 
> Hi David, andy,
> 
> David Nuescheler wrote:
> 
> >to me it seems like we have a number of people on this list
> >asking for a jdbc persistence manager, but the one that we
> >have (the "orm pm") does not receive enough development
> >support by all those people that are interested in it?
> >
> >if that really is the case then i would suggest that some
> >of the people that are using the orm pm are pitching in to
> >catch up with the rest of jackrabbit and make it
> >"production ready" ( whatever that means for an
> >unreleased project ;) )
> >
> >
> Thanks David, I'm glad somebody else than me is saying that :) (for
> those not in-the-know, I've been working on the initial implementation
> of the ORM-PM.
> 
> >i think that having another jdbc approach without scraping
> >the orm pm will only spread the seemingly small *developer*
> >base interested in supporting rdbms backed repositories even
> >thinner.
> >
> >
> I wonder btw whatever happened to the iBatis implementation that was
> done a while ago ? Any news ?
> 
> Anyway, my take on DB-based persistence managers is that they need :
> - a caching system for performance

caching is taken care of in another layer. caching on the persistence 
layer is redundant and could aversely affect the overall performance
by consuming to much memory which could be used more efficiently 
by jackrabbit.

> - to be able to handle transactions
> - to be able to handle commit/rollback

agreed. you get that for free with jdbc.

> - use mapping files to be able to change the table and column names as
> they might conflict

this depends on which approach you're taking. i favour the keep-it-simple
approach (2 column tables as discussed in other threads, i.e. no 
mapping files required). 

> - be as high-performance as possible (although we will always have the
> performance cost of network traffic)

that's always a good idea :)


cheers
stefan

> - allow for clustering
> 
> In those criteria, an ORM-based implementation seams reasonable,
> especially the Hibernate one. It is perfectly possible to do all this
> without an ORM, but it would mean re-developping part of an ORM anyway.
> 
> And as always, in terms of speed : memory > filesystem > db :)
> 
> Regards,
>   Serge Huber.
>

Mime
View raw message