> I just wondered if anyone had looked at either sO (<http://www.jdbms.org>)
> or ozone (<http://www.softwarebuero.de/ozone-eng.html>) as possible
> persistence solutions?
> sO is currently GPL'ed, but I could add it to my growing list of things to
> bug the developers about. ;-)
> ozone, on the other hand, is already LGPL'ed.
I'm hardly impartial in this discussion, but I'll discuss why I think there's a problem with the database paradigm for object persistence:
It may be that a Java implementation uses type information to segregate object instances into different array-like structures, and treats them as records, which would fix some of the problems of storing variable sized blobs to disk, but fails on objects containing vectors and such.
2) Storage of variable sized blobs under a database regime usually entails a double index: first a key->record mapping, the record contains a heap reference, and the heap is managed by an index mapping variable-sized region key to what is essentially an offset into a record.
3) Object references are not keys. Well, of course they are, or can be considered to be, but treating them as such incurs an index hit. You're not generally interested in treating object references as ordered, but this is what db indices are usually designed to do, at some considerable performance cost. Even if you use a hash indexing, you're hashing what is already an identity onto another.
These are some considerations underlying our design choices in coldstore (whose homepage, incidentally, has moved to coldstore.linuxbox.com) after looking carefully at several quite good db backends for object storage.
It's my opinion that, quite apart from the overhead implicit in marshalling data for persistent storage, access to object reference is the best argument for persistence being implemented below the JVM interface, and not above it.