DB4O Problem Fixed!

As I reported a couple of days ago, I was having a problem with a DB4O experiment I was working on. Basically, after about a million records, my application would raise an error saying that I had run out of heap space. I could increase the heap space, but I was unhappy with that solution – it produced only margin improvements, and then I ran out of heap space again.

German Viscuso, who seems to read my blog, suggested that I post my problem to the db4o user forum. I visited the forum, and I found several possible solutions, but I found one that worked.

Early on in my code experiment, I was using an index, but I commented that line out to see how that changed performance – then, I am embarrassed to admit, I forgot to uncomment the line. Users of db4o, please note, the memory requirements and performance of db4o change dramatically if you do not use indexes. Use an index. My problems went away the moment I uncommented the line that maintains an index.

I am sorry to have written a post that suggested that there may be a problem with db4o – the problem was mine. Everybody who uses db4o needs to know: use an index. In a relational database, this affects performance only. With a db4o object cache, it can result in a fatal error.

In my last post, I mentioned that I had some code to ensure that my objects were unique, but it tended to be slow. I was looking forward to getting a chance to use version 6.2, which supports unique constraints. As it turns out, using an index speeds up my inserts as well – it is now both fast, and the repository does not allow duplicates.

In closing, conserve resources, use an index. That’s the ticket. The code to use an index looks like this:
Db4o.configure().objectClass(Person.class).objectField(“firstName”).indexed(true);