[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ozone whitepaper?
> base class 'OzoneObject' to make a class a database class. Each database
> object has an object id. An instance of that class is stored as a whole
> chunk.
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"?
> Ozone has a three-tier-memory-managment:
> 1. Top: ObjectSpace: It caches database objects as real java objects. We
> call them active objects. The object space consists of table which maps
> object ids to object references via a structure called ObjectState. If I
> understand it right the ObjectState class is similar to your InstanceRef
> class. An ObjectState has the folloing structure:
> object id // unique instance identifer
> cluster id // unique cluster identifier where the object is stored
> object name // a possible name given by the user
> readLockers // transactions which have a read lock for this object
> writeLockers // the transaction which has write lock
> timeStamp // set, when a method is called for the 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)?
> 2. Middle: ClusterSpace: It caches database objects as a byte stream. We
> call them passive or death objects. These objects were loaded from the
> persistent store but the aren't deserialized. The buffer size of the
> cluster space can be configured.
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?
> The persistence space keeps a reference to the current cluster. All
> objects which are written are appended to this cluster. If the cluster
has
> reached its maximum size it closed and a new one is opened.
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).
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?
Kind regards
Evan@Obsidian.co.za