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: PersistenceManager & childNodeEntries
Date Tue, 01 Feb 2005 09:35:09 GMT
hi serge,

On Mon, 31 Jan 2005 16:44:53 +0100, Serge Huber <shuber2@jahia.com> wrote:
> Stefan Guggisberg wrote:
> 
> >yes, i did some fine tuning and it seems to be quite effective :)
> >
> >
> Indeed. But I'm now seeing some sluggliness in the Search indexing, but
> this is quite normal, indexing takes time.
> 
> >i assume you got me somehow wrong. i was not saying that file-based
> >persistence managers (ObjectPersistenceManager &
> >XMLPersistenceManager) are faster than db-based persistence managers.
> >
> >what i wanted to say is that if you're using a db-based persistence manager
> >then using a very *simple* serilalization format gives you a much better
> >performance rather than mapping the objcts to complex data models/db schemas.
> >
> >i did tests where i stored serialized ItemState objects as raw byte arrays
> >in relational  and b-tree based databases and the results were very promising.
> >take a look at the InMemPersistenceManager where i am doing exactly that,
> >storing serialized ItemState objects as byte arrays. the serialization is
> >handled by the static methods serialize/deserialize in ObjectPersistenceManager.
> >
> >
> Actually at first I did misunderstand what you meant, but when looking
> at the InMemPersistenceManager implementation I understood what you
> meant. Anyway, in the PDF I sent last week, the results seem to agree
> with you :)
> 
> >but this is just my personal opinion, feel free to do it your way.
> >
> >a word on the file-based persistence managers
> >(ObjectPersistenceManager & XMLPersistenceManager) which are storing
> >the data in serialized and xml format
> >in a file system abstraction (FileSystem interface):
> >i am totally aware of the poor scalability/performance when using
> >LocalFileSystem
> >on a windows box. blame the windows file system whose performance
> >detoriates very quickly if the number of files & folders increase. run the same
> >tests on a linux box (using ext3 or reiser fs) and the differences in
> >performance
> >will be dramatic. or alternatively use the CQFileSystem (day's unix
> >fs-in-a-file)
> >on a windows box. the default workspace configuration in jackrabbit already
> >uses cqfs (see src/conf/repository.xml).
> >
> >
> Ok. I also assumed it would be faster on Linux, but I didn't have time
> to test it. As for cqfs, what's the license on that ? Where is the
> source code ?

there's a LICENSE.txt in the jar file (cqfs-3.5.6.jar).  it's not
open-source but
it's free for non-commercial use. cqfs is an optional dependency in
the project.xml.
if you did run "maven jar" you should already have it on your machine.

search the list for "cqfs" or "CQFileSystem", there were a couple of posts
regarding cqfs.

> 
> >btw: there was a long discussion regarding performance & scalability,
> >the subject was "the 1mn test: first jackrabbit performance and
> >scalability tests".
> >
> >
> Ok thank you, I will look it up if it's available in the archives. I'm
> actually not entirely focused on performance, but this was the first
> thing I wanted to do to get a feel of how well Jackrabbit fared, as I am
> looking at it for some projects, and I must it's a lot more mature than
> I expected it to be !

great to hear that, thanks.

> 
> >i assume that this is just a configuration/maven issue. i'm sure you can
> >setup a separate project (e.g. a custom persistence manager)  that
> >has a dependency on jackrabbit and that can run the jackrabbit unit tests.
> >i am not a maven expert though ;)
> >
> >
> You were right :) Just after I sent my mail I managed to do just that,
> but I do require the source code of Jackrabbit as a parent project.
> Basically all I did was :
> 
>       <unitTestSourceDirectory>../../src/test</unitTestSourceDirectory>
> 
> >thank you very much for your valuable input. if you're ready to contribute
> >your custom persistence manager implementations we'd certainly be
> >interested. be prepared though for occassional changes in the
> >PersistenceManager interface.
> >
> >
> Don't worry about changes, as long as they actually improve things I'm
> all for them.
> 
> I've finally managed to put a first *very early* version of my code up,
> it's available here :
> http://www.jahia.org/~loom/orm-persistence-20050131-1630.zip
> 
> Basically what I've done is that I have assumed this would go into :
> 
> contrib/orm-persistence
> 
> So basically uncompress the zip in the contrib directory and it will be
> in the correct location. I've also included a README.txt file which is
> important because database-based persistence managers need a little more
> setup. I also had to document existing limitations and known issues...
> 
> As for the code, most of it was put together very quickly so I'm sure
> there are ways to improve it :) I just want to get initial feedback to
> improve things. Let me know what you think.

thanks, i will have a look at it asap.

cheers
stefan

> 
> cheers,
>   Serge...
>

Mime
View raw message