RE: Ozone

[William Uther <will+ozone-db@cs.cmu.edu>]

-- Falko Braeutigam <falko@softwarebuero.de> wrote:
> On Tue, 14 Mar 2000, William Uther wrote:
>> Hi,
>>   I'm somewhat surprised people are having major difficulties.  I compile
>> and run Ozone 4 on a mac (jdk 1.1.8).
>
> The currently released code is JDK1.1 compliant. However, I've started
> coding an OzoneClassLoader to handle the reloadClasses() problem. This
> code really needs jdk1.2. I don't see an jdk1.1 compliant way of doing
> this.

JDK 1.1 can handle classloaders.  I'm not too familiar with jdk 1.2, did
classloaders gain extra functionality?

BTW, there is no JDK 1.2 for the mac.  (Apple is working on one for use
with MacOS X, but is also still negotiating the license with Sun so there
is no guarantee it will be released.)

> BTW, I ran into some tricky problems with the ClassLoader. Anybody
> willing to help with this?

I'm working on other things for the next month.  Sorry.

>>   - Ozone requires more work than some other OODB's I've seen in that it
>> requires you to specify an interface for each 'ozone class'.  The problem
>> I've found with my project is that almost everything ends up being a
>> proxied class and so you end up doing work to keep things in sync.  Other
>> systems just require you to build the implementation and then generate
>> both the interfaces and proxies using an OPP-like tool.
> This has to be changed. The XML descriptor and the generetor code is
> already ther I need to incorporate it.

Will XML descriptors really help?  I haven't looked at OIG yet but, from
what I understand, all that does is change the format from a java interface
file to an XML file.

> Damn, it takes me to much time to
> write those f*cking English emails... ;)

I'm sorry.  I can count in German, but that's about it.  We Aussies are
almost as bad as Americans when it comes to learning foreign languages.
Sigh.

>>   - Ozone doesn't currently allow proxied objects to be used as keys in a
>> hashtable.  More generally, it doesn't allow you to use an object where
>> non-standard serialization is used and accesses a proxied object during
>> de-serialization.  This is a tricky bug to fix (I think I know how, but
>> it would require some non-trival architecture changes and hacking).
> So what can I say here, Will? Fix it and send the path! ;)

  Well, the concept is simple.  When you serialize a proxy you look to see
if the serialized version is being stored or sent outside the DB.  If it is
being sent outside the DB then you treat it as normal.  If it is being
stored, and the object it references is in the same cluster, then you
serialize the object as well as the proxy.  This is really just a change in
order as the object is going to be serialized into the cluster anyway.
When you read the proxy back in, you do a similar check.  The proxy can
read in the real object and add it to the cluster.  Then if something
references that proxy during de-serialization the correct object will
already have been added to the cluster.
  Finally you need to re-order some of the code so that a cluster becomes
active in memory when it starts being de-serialized, and the
de-serialization just adds objects to it as it goes.

  Again, I have no time to work on this in the next month.

> Anyway, I don't
> really sure if this really is a bug. Again Will, do you think you need
> exactly this szenario?

The only way I can see to fix this is to make a series of hashcodeproxy
objects that take the original key and cache the hashCode.  This means
going through and making sure that everything depends upon non-changing
info (at them moment the hashCode method depends upon the hashCodes of its
children, which could change as they are de-serialized).  This is doable,
but not a nice solution.  It is not going to be space efficient, and that
is my concern.  Speed is not so much of a problem in this section of code:
the hashCode is only really used when objects are inserted - caching it
wont speed things up much at all.

My project was a simple version control system.  I was compressing the
documents into a cluster of ozone objects, one for each line.  The
hashtable was catching duplicates for me.

later,

\x/ill          :-}