[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ozone whitepaper?



Hi Evan,

> What happens to references, eg. are they not stored as object IDs?
> (Persistence via reachability?) As I understand, when
> Java serialises, it includes all objects referenced as well.
> So do we get some objects stored "redundantly"?

Yes, I see the problem. We would save objects redundantly and if we have two
ozone objects which reference the same java object we could run in rouble when
we deserialize them. The solution for this problem is: If we know that we could
get such a 'cross reference' we should use ozone objects instead of java
objects because it's no problem if two ozone objects reference the same ozone
object.

> So your ObjectSpace caches all objects that have 
> been instantiated from the persistent store, I mean 
> read from the disk at some point, in particular
> keeps track of references to all database objects
> in memory (and their database objectIDs)?

Yes, it does. But it caches not all objects which were ever been loaded. This
does the ClusterSpace: It caches the serialized version of the objects as a byte
stream. If the ObjectSpace needs to instantiate an object it gets this from the
ClusterSpace. 

> This might only be a fraction of the objectstore though (in the 
> case of large objectstore) -- how do we find other objects
> not yet in the ClusterSpace by their ObjectID?

We load the cluster which contains this object from the PersistenceSpace and
insert this cluster into the ClusterSpace.
  
> Ok, as objects are updated, new "states" are always written to the current
> cluster, where we have one current cluster open at a time, for writing.  In
> terms of fetching existing objects from database, how is that achieved, eg.
> in the case where we might thousands of clusters?
> 
> > There is no need for a special disk address becaus[Be in ozone we load
> > the whole cluster and insert all passive objects into the ClusterSpace. 
> > This won't work very good if we don't have the ClusterSpace, but we have
> ;-) 
> 
> I'm not I sure I understand the disk storage mechanism, in particular in
> terms of fetching objects by ObjectID. I understand that we have clusters,
> and read clusters from disk into the ClusterSpace, which allows us to know
> which objects are cached there, and of course also deserialised objects in
> the ObjectSpace we know about too. But what about all other objects -- how
> do we know where to find them on disk (in the case of large objectStores).

The ObjectSpace keeps a table of _all_ ObjectStates of the datebase. When we
start the ozone server the states are read from the database, of course this
may take a while. Each ObjectState has a reference to its deserialized ozone
object. This reference is 'null' if the object wasn't fetched yet from the
database. The ClusterSpace keeps track of the size of all fetched objects. If
the sum of all object sizes is greater than the size specified by the database
administrator, the ClusterSpace deletes some objects from the memory and be
setting all references to it to 'null'. Now the java garbage collector can do
its work. 

To keep the memory usage of the ObjectSpace constant we use a so called
DiskHashtable for the mapping ObjectID-ObjectState. The DiskHashtable keeps an
amount of ObjectStates in the memory and writes the all others temporaryly to
hard disk. It simulates a swapping mechanism for the object state table.

> In terms of objects that are added/updated, I understand that we 
> write to the current cluster, and note the leak to the previous cluster
> where an invalidated state of the object is still serialised, and 
> at some stage we "compress" clusters to effectively remove
> invalidated serialised states. Where do we note that this 
> new cluster is where we find this object now?

Before writing the object and its ObjectState to the new cluster we set the
ClusterID of the ObjectState to the new one.

Bye
Gerd

--
________________________________________________________________
Gerd Mueller                               gerd@softwarebuero.de
softwarebuero m&b                    http://www.softwarebuero.de