Re: using built-in db

 
> I'm finding the built-in DB quite cool. Is there a reason I 
> shouldn't be using it? Does anyone know what its performance 
> limitations and points to consider are? The site I'm building 
> now will probably never have more than 1000 total objects, 
> and I'm assuming that should be more than fine, but future 
> planned projects will have more. At what point do I need to 
> give up the built-in object db?

I'm not sure what the limits are, but I given that large numbers of
object would mean large numbers of small files in a sinlge filesystem
dir, I think the limits would be more determined by the underlying OS
filesystem.

A quick test in creating large number of a simple prototype with just 3
non-reference properties and then iterating over them to change a 1
property gives:

created 1000 books in 0.06s scanned 1000 books in 0.05s
created 5000 books in 0.741s scanned 5000 books in 0.14s
created 10000 books in 7.231s scanned 10000 books in 0.26s

(these are on a P4 3.2ghz, with winXP, NTFS, jdk1.6 default vm memory
settings)

and even for the later tests, the CPU usage of the helma process never
went above about 60% and most of the time was close to 30% which does
also seem to indicate that its disk io that is the limiting factor.

BTW Not sure if this is documented anywhere, but one nice feature of
using the xml data store is you can just delete an apps whole folder
inside the db folder, restart the app (with the manage app webconsole)
and hema will recreate a new lcena db folder for the app!

Also be aware that if you go use the xml-based datastore, you won't be
able to use the more advanced features of the data mapping layer like
filters and groupby sorting for collections.

Someone like Hannes is probably better placed to say what the xml
datastore is like in features like thread safety and whether it
implements things like atomic transactions.

Actually while writing the tests above I did notice that if I did
res.abort() after adding the objects to the collection, they were left
in the in-memory cache but not persisted to disk - I think this appears
to be a bug...

Maks.