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

Fwd: Re: ozone whitepaper?

Hi to all !

Another mail from and to Evan.

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


Hi Evan,

> In terms of objectID to disk address indexing, I mean for quick access to
> an object
> from its objectID, how does that work? As I was saying, my idea
> wass to have special (objectID to disk address mapping/index file)
> which I call InstanceRef, but let me call ObjectRef, as opposed
> to the ObjectID -- the ObjectRef tells us where to find
> the serialised object of a given ObjectID. So the ObjectRef
> table (on disk) has: 
> 
> objectID: the key
> clusterNumber: which cluster that object is actually serialised in 
> diskAddress: which disk address in that cluster/file we can find it 

There is no need for a special disk address because 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 ;-) (in ozone of
course).

> I was calling each file a "store", but will call it a cluster to use
> your terminology.
> 
> Of course that object could change, in which case the ObjectRef
> itself leaks, because updated version of that objectID is stored
> at different address. As with objects themselves, I don't
> want to dive into files, so rather "leak" the ObjectRef,
> where we can "compress" later.

In ozone the ObjectRef never fails, because the address is imediataly updated
after storing the object. 

> So it seems we are thinking along similar lines?
> 
> I'm only considering the disk storage mechanism
> at this stage, and haven't progressed to ClusterCache,
> ObjectCache, etcetera, or even Transaction commit
> procedures -- just the basics of persisting objects 
> to disk, in particular
> 
> First we have:
> 
> objectID = database.writeObject(object, clusterNumber);
> object = database.readObject(objectID);
> 

> My design goals were as follows:
> 
> 1. total parania about corruption, so rather take 
> performance/space penalty, even an order an magnitude,
> in return for robustness.

Yes, this really important ! ozone is going to be a EJB-container and in this
case corruption would be _extremly_ bad !
  
> 2. as fast as possible, eg. delay "optimisations" for later --
> "shoot first, ask questions later," like what SolidTech were saying.
> 
> 3. geared for distributing data redundantly, eg. duplicates on 
> different drives (application-level "RAID").

Why application-level "RAID" ? E.g. for Linux there as an excellent software
RAID.

> 4. layered design, where basic layer gives us mechanism
> to persist objects. Collections are then implemented on top of
> that layer. Applications that just 
> have a few objects (eg. address book in PDA) could 
> embed fundamental layer in their application.

Interesting idea. We have special collections for ozone and we're going to
implement ODMG (allthough we are not very happy with that, but industry loves
standards). Also we could adapt the PersistenceSpace to be a simple persistence
engine for PDA's.

> 5. Giving flexibility for optimisations to be hand crafted in classes --
> specially for "system" classes on higher layers, eg. collection
> classes.
> 
> 6. pure OO -- no SQL. Queries are performed by instantiating
> each object in an extent and invoking some method.

That's what ozone is all about ! Absolutely no query languange. Only Java for
class description and object manipulation. At the moment each method invocation
for a database object causes an implicit transaction. But we have to add also
explicit transaction for EJB compliance.

> What do you advise me to do now? Are my design goals in line with yours?
> If so, how do I collaborate?

I see two possibilties:

1. We try to optimize the memory managment of ozone together.
2. You could also develop your own 'PersistenceSpace' which could be compatible
ozone. We could develop a plugin interface, so that a user can choose which
memory managment (s)he want to use. 

I see a third way: at the moment ozone leaks class versioning, i.e. migration
of objects from an older class version to a newer one. I think, this is also a
important point for persistence managment. Sounds that interesting to you ?

Any a other ideas ?

Best regards
Gerd

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