Corey Brown wrote:
Hi Corey,

judging from our customer database, you have also been
experimenting with db4o.

Since you still seem to be looking for other solutions,
would you mind posting a short comment what you liked
and disliked about our product?

Thanks.


I fully agree with Michael Wein:
Please ignore the distracting postings that have nothing
to contribute to this group.


I also found Paul DeWolf's explanation of Objectivity's
OIDs very interesting. Thanks Paul!


Here is how db4o does it:
A db4o ID is a physical pointer to a physical pointer.
We do not use any paging at all. Since the physical
pointers use comparatively little memory, it's possible
to cache them.

Objects are immediately written to the database file
when they are modified ( ObjectContainer#set() ).
Upon transaction commit, the second level pointers
of all modified objects are redirected to the newly
written object data. To make this system completely
fail safe, the database file is set to "commit mode"
and a list of all the pointers that are about to be
rewritten is written to the database file. If the
VM or the computer breaks down at any point in time,
commit is resumed when the database file is reopened.

Our ID- and file-system does not scale as nicely for huge
databases as the one that Objectivity or Versant uses
but direct object access will be faster for "small"
databases up to 1 GB, since less indirections are needed.


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

"Carl Rosenberger" <carl (AT) db4o (DOT) com> wrote

Hi Carl, nice to hear from you again. Yes, we have experimented with
db4o and we find your product very easy to use and quite robust. There
are
only two short comings for us at this point, the lack of scalability
beyond
a safe 1GB boundary and the lack of a set of "smart" collections. In our
app we often have to deal with very large collections of objects and we
need to be able to pull the collected objects from the database in a
very
controlled fashion. I know your team is currently working to correct the
smart collection problem so I understand that the problem will be going
away shortly. We're also still tied to our OEM agreement with our
current
supplier, so it may be awhile before we can change.

I really do like your product though and am very glad to see that you
have decided to stick with it. I know you're going to be very successful
in the PDA and embedded system markets.

Carl, two things come to mind after reading your explanation
of how db4o works:

- How do you control the clean up of the objects that have already
been written out, if the resumed commit fails? You esentially have
a two phase commit. In the first phase (during normal processing of
objects) the individual objects are written to the db into areas
other
than their original slots (spaces). In the second phase of the
commit
process, the actual call to commit is responsible for fixing up the
pointers. What if you never make it to the call to commit, but yet
you
have objects written to the db. Does the transaction log take care
of
deleting the "newer" versions of the objects during the recovery
phase?

- During the fix up stage, is the physical location of the object
changed and
the old version removed? How do you fix up the other objects that
refer
to the updated objects?


Thanks again Carl for sharing the implementation details of your
product.
Keep up the good work.

--Corey

Hi Michael,

I'll admit very little knowledge of Versant's architecture and no experience
using it. All I know of the product is second-hand, so I shouldn't have put
that in.

The centralized LOID lookup that I've heard about probably comes from the 16
and 48 bit division versus our 4 16-bit fields. I can see advantages to
both.

Thanks!

Paul

"Michael Wein" <MichaelWein (AT) web (DOT) de> wrote

Corey Brown wrote:
We do have a couple of customers that use db4o for way more data.
What they do is split data up into multiple databases. You can open
as many databases as you want at the same time. In client/server
mode a client can request access to another database from the client
side. We also provide the possibility to store blobs in separate files
outside of the main database file.

The only usecase where the above approach will not work nicely:
If you have a huge number of objects of one class ( > 1 GB) and if you
want fast queries within this set.


Agreed, this feature really is very important and it's right on the top
of the "what's next" list.


Thanks, that's where we are headed.

db4o also is a good fit for real-time systems. I am quite sure
that there is no comparable product with a storage performance
(INSERT) that comes close to ours.


If VM or computer crash after writing objects and before commit,
this space in the database file will be lost. You can get your
database file back down to minimum size by running the Defragment
tool.

The above is a trade-off that we chose in favour of speed and
stability.

We could also write records of our freespace-management system
back to disc with every object that we write, but to keep these
writes failsafe also, would require a couple of more file write
cycles and file syncs.


No, but since these new versions are not referenced anywhere,
they only take up "dead" space in the database file and do
no harm otherwise.


During the fix-up the physical location of new objects is not
changed, only the pointer that has previously been pointing
to the old version is modified to point to the new version.
Yes, the old version is "removed", it's added to the
"freespace" entries.


That's not necessary. They always point to the one-level
redirection pointer.


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

"Michael Wein" <MichaelWein (AT) web (DOT) de> wrote

DeWolf is already in my twit filter so I have not read his full post. If you
prefer to listen to twits give longwinded dispositions on inconsequentials,
by all means, ignore me and listen to DeWolf.

A physical pointer is a physical pointer even if it points to a physical
pointer.

"Corey Brown" <corey (AT) spectrumsoftware (DOT) net> wrote

Sorry, we only have our Java binding to our C++ libraries. It's faster that
way, and we don't want to try to maintain two code bases.

I'm glad you're finding new acceptable products. I used to think that there
was a database holy grail that would be found someday, but now I realize
that there are way too many variables in application requirements for that
to happen.

If there really was a mathematical model that represented real life, the
equations would not converge on a single solution.

Thank you. Good luck with your product!

Paul

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

Inconsequential? In what context? Given the context of the conversation
that we were having, Mr. DeWolfs contribution to this post was certainly
relevant and useful.

Paul DeWolf wrote:
There is a mathematical model of the real world --- the relational data model.

I assume you think you've disproved relational theory.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)