Re: What makes an OODBMS different from an RDBMS?

Clifford Heath wrote:
[ACID transaction disk IO]
> At this point, I think I've thrown down the gauntlet obviously enough.
> Perhaps some OODBMS vendors would like to discuss how they address the
> points I've raised?

I have been reading along all of your postings on object databases and I agree with many of your points.

Judging by the widely spread attitude towards object databases and lots of customer stories I have read, some of the "old-time-object-dabase-vendors" must have done a dreadful job for the scene by providing horrible implementations.

We have a concept for an efficient 100% failsafe write mechanism that does not need to write "fixed pages". Instead every single object is associated with a transaction. An internal "pointer-system" in the database file works with four levels:

(1) root
(2) transaction
(3) pointer
(4) object

The organization of the pointers:

root > transaction

             ^
           pointer > object

A transaction is commited by switching one byte.

We do fit into your summary very well, since the transaction part of this design is not implemented yet.

However we do already write data in the right order:

- Changed objects always get a new and free space in the database file
- write the object first
- switch the pointer afterwards

With this algorithm we already have an extremely stable system which is very resistant to computer crashes, even if they occur in the middle of writing processes.

Our engine is *not* a memory-based system like your "gauntlet" suggests for most systems. [1]
Every change is written to the database file immediately after it is applied. commit() flushes indices.

We are on the way to a 100% secure system. Could I assure you that we will get there?

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com


[1] One of the popular pure Java SQL databases also is a
memory-based-system by the way.