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

RE: Ozone

On Tue, 14 Mar 2000, you wrote:
> -- 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?
Yes, jdk1.1 can handle classloader but the API and semantics has changed.

An OzoneCLassLoader is the way to throw away and reload classes when the client
requests a reloadClasses() - that's the '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.)
So we need both versions. Should be possible to make this configurable
at runtime, I hope.

> 
> > 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.
Yes, but once the interfaces are no longer needed to hold extra class
information I may consider make proxies that do not need the Java interfaces
that you are to lazy to maintain ;)

> 
> > 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.
Wow count in German... great start. ;)

> 
> >>   - 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.

ozone uses simple serialization to store clusters. It just writes the container
of a cluster one by one. If one or more target objects contain proxies, they
are written as normal object. In fact they are normal objects. ozone is not
aware of the proxies that a container or a cluster may contain nor does the
writeCluster() method write containers and proxies in a defined order.

Calling another database object in the serialization code (via hashCode()) is
not a good idea because ozone does not expect it. Consider to following. A
cluster is half loaded when the hashCode() of a taget is called. Then the
execution leaves the ozone kernel code in an inconsistent stage. ozone assumes
that loading a cluster is atomar. (of course!?)


Falko
-- 
______________________________________________________________________
Falko Braeutigam                         mailto:falko@softwarebuero.de
softwarebuero m&b (SMB)                    http://www.softwarebuero.de