Hi,

Just wondering... the Objectivity docs says the OID may change if the
object moves to a different page. But I plan to cache objects in the
Java client (i.e. hold a list of Persons in a listbox.) I have a
middle tier that serializes the objects to Java clients. That is,
Objectivity doesn't know about my true clients.

But if another client suddently changes the object so that Objectivity
moves it to another page, the OID changes and my client's OID is
invalidated!

Isn't this a flawed design?

"hantheman" <hantheman12 (AT) hotmail (DOT) com> wrote

I would think that in order for that to happen the object in question
would have to be deleted and then added back to the system. In any case
it's just a matter of catching the exception case and then rebuilding
your
external list of objects over again. Check to make sure that there
isn't
another mechanism for directly accessing persistent objects from
external references other than OIDs.

--Corey

"hantheman" <hantheman12 (AT) hotmail (DOT) com> wrote

OID in general is flawed. However, spontaneously changing OID's would seem
more than a little over the top.

The OID would change if your application moves the object.
An object update doesn't change the OID.

I don't think you ever run into a problem unless you delete or move an
object.

An OID compares somewhat to a C/C++ pointer.
Both constructs point to an object ... if the object is gone ==> your
pointer is stale.

Markus.


"hantheman" <hantheman12 (AT) hotmail (DOT) com> wrote

In other words, OID is just a physical pointer.

"Markus Schumann" <go4shoe (AT) hotmail (DOT) com> wrote

OID is exactly what relates a row to its physical storage location.

Bob Badour wrote:

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

In Objectivity/DB an OID is a physical pointer. This provides for
excellent
performance at the expense of not being able to move the objects around
in the repository freely.

Other databases, like Versant, use logical OIDs, which allow the objects
to be moved around more easily, but also are impacted by the expense
of a redirect table lookup.

--Corey

Objectivity's OID is not a purely physical pointer. There are actually a
three logical to physical indirections. It's easy to think it's a physical
pointer when using it because of the speed of the look-ups, but it's not.

The first 16-bit field of the 64-bit OID represents the "database", which is
actually a catalog of files, which allows you to distribute and redistribute
a federation of databases without changing object IDs.

The second 16-bit field is a container ID that is physical within the
database.

The third field is another logical page ID that is mapped to a physical
page. This allows Objectivity to change the object (including its size)
without changing the logical OID, and is a critical difference between
Objectivity and hierarchical and network databases. This indirection also
allows Objectivity to provide multiple versions (consistent and atomic
views) of the database while it's being updated.

The fourth field is a slot, which is has another logical to physical
indirection that allows Objectivity to defragment pages and move objects
within a page.

The logical OID is permanent for the life of the object unless the object
needs to be moved to a different container. Since containers can grow to
4GB, this is rarely a problem.

Versant's problem (in my opinion) is that there's a single centralized
logical to physical indirection, which leads to performance and scalability
limitations.

There's an obvious trade-off between physical pointers and logical IDs (all
of which ultimately resolve to physical pointers). If the pointers are too
physical, there's inflexibility. If there are too many layers of
indirection or the indirection is completely hidden from the application,
not only does performance and scalability suffer, optimization becomes
limited to abstract rules that don't address the real problems.

Bob and others will deny that that ever happens in a "relational" database,
but it's obvious as soon as you install and use a SQL database. It would be
interesting to experiment with a "third manifesto" database, but so far no
one's been able to implement one.

Objectivity's OID strikes a great balance. It's fast enough so that it
seems like you're working with a physical pointer, but the layers of
indirection avoid the problems of hierarchical and network databases. It's
not magic; it's just using some of the same concepts that have worked very
well in other applications. The OID is in some ways very similar to an IP
address and also similar to handles (e.g. Java references) in software
memory management.

Paul DeWolf
Systems Engineer
Objectivity

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

"Paul DeWolf" <paul (AT) thievesandkings (DOT) com> wrote

Don't go anywhere near to this toxic waste dump. There's just no talking
to Bob or his pals.

Paul,

Thanks for the excellent write up on Objectivity's OID implementation.
It's
been a fairly long time since I had a look at Objectivity or Versant for
that
matter, so my remaining knowledge on both databases has become quite
rusty. I've been concentrating on small embedded Java ODBMS
implementations
for the last few years and find them very acceptable for most of the
work that
we have been doing. Does Objectivity have a product that works in this
space? Not just a Java binding for your enterprise offering, but a true
100%
Java ODBMS? We played with Poet's J2 (FastObjects) implementation a
little while ago but couldn't come to grips with the pricing structure.
Our application
embeds a Java ODBMS and we need a pretty good price point in order to
keep the costs down and the margins higher.

Thanks again for the refresher course Paul :-) :-)

--Corey

On Wed, 17 Dec 2003 20:03:17 GMT, Paul DeWolf wrote:

Having worked both with Versant and objectivity, I never had problems with
Versant's LOID concerning performance or even scalability (remember that
they are 64 bit splitted into 48 bit object and 16 bit database IDs). But
the same also holds for objectivity ;-) I believe that in reality it is
very easy to work with both realisations (probably objectivity's is a
little bit harder to live with because of its page server concept).

Thank you for the very detailed and precise description of OIDs! Please
ignore Bob and other trolls.
--
Michael Wein