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

Fwd: Re: ozone whitepaper?

Hi folks,

This is a mail I've wrote to Evan. He is interested in ozone
internals. I've  fowarded it to list because it could be of interest for some
of you.

----------  Forwarded Message  ----------
Subject: Re: ozone whitepaper?
Date: Wed, 29 Sep 1999 09:21:08 +0000
From: Gerd Mueller <gerd@softwarebuero.de>


Hi Evan,

> I'm not sure how practical such a mechanism is,
> but I'm thinking of applications where data is relatively
> static, and/or mostly appends -- and I'd rather 
> risk performance penalty in return for
> robust journaling-type mechanism like this...
> 
> What do you think?

This is an interesting approach. Especialy that you wan't to store all in
instances of a class in one file. There are some parallels to ozone. I'll
try to explain how it works:

As you may know from the ozone examples you need to inherit from a special
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. 

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

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.

3. Bottom: PersistenceSpace: This is the place were database objects are
really stored. Database objects are stored in clusters where a cluster is
one file. Each cluster has an id and the filename of the cluster _is_ the
id. A cluster has also a limited size which can be configured. 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.

So, if we commit database objects, we have to do the following steps:

1. Create, update or delete objects within a transaction.
2. While transaction-commit we call ObjectSpace.commitObjects with a 
   list of objects which were created, updated or deleted
3. Calling ClusterSpace.commitObjects
4. Calling PersistenceSpace.beginTransaction, which sets a flag with the 
   current transaction id at the hard disk
5. Calling PersistenceSpace.writeObject for all changed database objects
6. If the object was updated or deleted we call first Cluster.writeLeak,
   except the objects was created. For each cluster file there is also a 
   leak file, which contains all objects ids of the cluster which are 
   invalid, because the object was removed from this cluster and maybe 
   moved to another one. A leak entry consits of:
      object id of the object
      transaction id where the leak was written
      the complete leak size of the cluster
7. Appends the object at the current cluster except the objects was deleted
   from the database. The following is written:
      object id 
      transaction id
      object state of the object
      the object it self
8. After all objects are written we compress all clusters where the leak
   size is half of the cluster size. Compressing means moving all objects
   which are not marked with a leak to the current cluster and deleting
   the compressed cluster.
9. After that we remove the transaction flag from the hard disk and the 
   commit was done.

What happens if the database crashes while commit ? Then we will find
the transaction flag after restarting the server and we roll back the
complete transaction.

Okay, this is only a raw overview. There are a lot of other things, e.g. the
managment of the buffer of the cluster space. 

I hope it is understanable because of my English. Exmplaing all that in German
is not easy, but in English it ten times harder for me :-(.

If you've got further questions, please, write back.

Best Regards
Gerd

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