[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of the ozone project
On Thu, 14 Sep 2000, Martin Harper wrote:
> Falko Braeutigam wrote:
>
> > Hi all,
> >
> > I have to forward this message, which I sent to Raul some days ago after he
> > unsubscribed the list, to the list because it IMO reflects the status of the
> > ozone project very well. Comments are - as always - welcome.
>
> ok.... (this is longish)
Thanks for the response, Martin ;)
>
> > ---------- Forwarded Message ----------
> > Subject: RE:
> > Date: Wed, 13 Sep 2000 12:29:05 +0200
> > From: Falko Braeutigam <falko@softwarebuero.de>
> >
> > Hi Raul,
> >
> > I very appreciate your honest answer.
> >
> > On Wed, 13 Sep 2000, you wrote:
> > > Thank you for asking.
> > >
> > > I was very interested and I have been studying ozone much.
> > > But I had serious problems with Ozone:
> > > - I had a difficult Exception message I until now have not solved.
>
> On a sidenote, it would indeed be good if the exception handling of Ozone was
> cleaned up. As I see it, the main problems are...
> Many methods on Ozone are declared as throwing Exception, whereas it would be better
> if they could throw just OzoneRemoteExcs, and possibly some others, like IOException
> (haven't checked code).
I agree in general - some more information in the exceptions would be fine. But
it would be a fairly bit of work to rework this...
> OzoneProxies generated by OPP rewrap exceptions in unexpectedexceptions - but the
> wrapping only wraps the string from getmessage - it would be better if they were
> more similar to java.lang.reflect.InvocationTargetException, and wrapped the entire
> exception. On a similar note, they should probably not touch the stack trace.
I agree.
>
> In any case, the logger on the server tends to be the most useful for tracking down
> bugs - at least for me.
>
> BTW, It'd be neat if OPP flagged uses of this where self() should be used in *Impl
> files - that'd be one less source of bugs... :-)
good point!
>
> > > I still appreciate all work that has been done, but to me it looks like
> > > ozone needs a total clean up and a strategy overview.
> > ozone needs a clean up and a strategy overview? Fine! What are your ideas? I'm
> > totally open minded in this regard. And, even more important, why don't we
> > discuss this in the list?
>
> I do think a fully-fledged ODMG wrapper to Ozone would be good, if a lot of work -
> the current interface is great for internal stuff - between different modules of the
> same program - because you can do all the database work in a single
> implicitly-transactioned method call, set up precisely as it's needed, and optimised
> to do the work in the best way possible. Unsurprisingly, really, since that was what
> it was designed for...
>
> However, if you're writing middleware, and you have to provide access to parts of
> the database to external programs, then you're in trouble - you either have to make
> the types of access very limited, or you have to implement a proper query language,
> in which case you might as well pick OQL because it's the one everyone else uses.
Hmmm. I don't see the relation between ODMG and the use of ozone for writing
middleware. Can you explain more?
Ozone supports explicite transaction demarcation and, even more important,
two-phase-commit via the native ozone transaction interface and via a JTA
compliant XAResource implementation. _These_ are things that are needed to
use it for middleware, IMO.
ODMG mainly consists of two parts: the ODMG specific Java database API and OQL.
I tried very hard to implement the ODMG API on top of ozone but it is nearly
impossible (at least for me it seems so) to do so because ODMG is totally not
aware of ozone's single instance (proxy) architecture.
This is one reason why I don't like "standards" for OODBMs: ODMG claims to be a
universal standard for all kind of OODBMSs. ozone on the other hand _is_ an
OODBMS. But ODMG does not support the ozone architecture... Can we call it a
"standard", if it simply ignores an entire class of OODBMSs???
> It's also difficult to get Ozone to dynamically optimise itself for the type of
> queries it's receiving - as an example, I store a bunch of computers in Ozone, and
> some simple information on each. What's the best way to store them? If I hash by
> name, then it'll be dog-slow if most of the queries are based on IP. If I hash by
> IP, then it'll be dog-slow if most of the queries are based on name. If I make two
> hashtables, one for each of IP and name, then it'll half the speed of adding and
> removing entries. It gets worse with people, who have about 50 different attributes
> each...
Okay, this is the question of a descriptive query lang. As I mentioned in my
last post, I'm not against a descriptive query lang but I don't think that OQL
(and any other string based solution like JDO) is a good interface for it! I
prefer the SODA approach much more.
Anyway, if somebody is going to make an OQL interface for ozone, fine, I would
not tackly this or something.
> That could be fixed with a new subtype of Set , perhaps, though I expect that too
> would be a lot of work. But defining a skeleton class for it now and a simple (slow)
> implementation would be a good start. Preferably one that implements java.util.Set,
> rather than .DxLib.DxSet - better yet if it implemented org.odmg.DSet. Seems like
> the sort of things someone somewhere else has already done... I hope so.
This is a good point. All descriptive query langs that I can think of are set
based. Implementation are fast because they can use indeces. There are three
candidates currently: OQL, SODA and, which I'm particularly interested in, a
set oriented XML query lang that yet has to be defined. All could use the same
ozone-query-kernel but provide different APIs/fron-ends. Sounds like this could
put ozone into orbit ;) Well, much work... What do others think?
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com