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: Performance issues of using "object" repository rather than "orm"
Date Wed, 18 May 2005 13:03:24 GMT
On 5/18/05, Philippe Girolami <philippe.girolami@digiplug.com> wrote:
> Stephan,
> 
> > <disclaimer>
> > i have to admit that i am biased. i love simplicity and easy
> > deployment and
> > i am not a huge fan of ORM.
> > </disclaimer>
> I'm all for simplicity. Whether that means ORM or not depends on the case :)
> 
> > Object PM
> > ----------------
> > pro:
> > - very easy (i.e. zero) deployment
> > - very simple yet efficient
> > - excellent performance on a decent file system
> > - no network transport overhead
> >
> > con:
> > - scalability for very large data sets?
> Hummm... I'm talking of millions of "nt:file" nodes here. Each file is
> linked to one object with a number of attributes some of which will be
> references to other nodes.
> Because of this I'm thinking of writing our own custom PM if we use ORM as
> we will not want to store the binaries in BLOBs !
> 
> > - non-transactional
> meaning XA or is the Object PM not even atomic when using
> versionning/locking ?
> Ok, I could look at the source myself to figure it out but if you have the
> answer for everyone to share that would be great.

XA support is implemented in a higher level in jackrabbit. you'll have XA 
support in jackrabbit independant of your choice of PM. what i meant by 
'non-transactional' is that the underlying store (in that case the file system)
is not transaction capable.

dominique is the real expert in this area so he might be able to provide more 
detailed information.

cheers
stefan
> 
> Thanks
> Philippe
> 
>

Mime
View raw message