[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ozone db
- To: jacob@jdbms.org
- Subject: Re: ozone db
- From: Falko Braeutigam <falko@softwarebuero.de>
- Date: Wed, 22 Mar 2000 14:18:27 +0100
- Cc: ozone-users@ozone-db.org
- In-Reply-To: <38D801C0.E4DCDBCB@globalmedia.com>
- Organization: SMB
- References: <sO.9536733800291656334@stud.uni-frankfurt.de> <38D801C0.E4DCDBCB@globalmedia.com>
On Wed, 22 Mar 2000, Alex Cruise wrote:
> Gerhard Paulus wrote:
>
> > /*
> > On another note, I would like to get your comments on this other open
> > source Java database--
> >
> > www.ozone-db.org
> >
> > How similar is it to yours? How different is it from yours?
> > */
> >
> > Both have the same objective: to write/read Java objects to/from disk.
> > But ozone and sO use very different paradigms to do this.
>
> [...]
>
> > For sure, sO also comes with methods to pull in all Java objects of network (graph)
> > in one go and so on, but at least conceptually the ODMG approach is much more elegant.
> > sO sees itself more as a reliable and fast work-horse over which you have full
> > control and sO relies on only one single standard: core 1.1 Java.
>
> First post, sorry if this violates any rules ;)
>
> It's my understanding that Ozone is also devoted to using RMI, so that all persistent
> objects can only be instantianted on the server, then remotely controlled from the
> client. Unfortunately, the standard Java 1.1 version of RMI plays fast and loose with
> TCP/IP port numbers, and is therefore almost unusable through firewalls. If your
> middleware and database server are always going to be on the same side of a firewall,
> there isn't much to worry about.
ozone is based on a specific ozone/RMI. This is pretty comparable to Java RMI
but has different API and implementation.
However, I did not yet use it through a firewall so I don't know if it's
possible and what are the actual problems.
>
> Ozone seems to have chosen the single-instance strategy to alleviate the cache
> synchronization problems that active-client OODBs like sO use; personally I prefer sO's
> "registered listener" approach (at least as I understand it)... It's a lot less scary to
> an only moderately experienced Java programmer like myself.
ozone tries to hide as much as database specific things from the programmer. In
the best case you can use the same code for transient and persistent version of
the application. What is scary about that?
>
> A few questions:
> - Has anyone done comparisons (features, performance, whatever) between sO and other
> (optionally pure Java) OODBMSs? I noticed the TPC-W benchmark code, but I'm nowhere near
> mentally ready to execute it.
> - Has anyone worked on W3C DOM serialization of XML documents and
> XQL/XPath querying? Ozone has this feature, and it's one I'm keenly interested in. If
> both projects are GPL'd (see http://www.ozone-db.org/ozone8.html) , is there any reason
> we couldn't grab some of their code and adapt it?
The DOM implementation that ozone uses is pretty much the original OpenXML
code. We needed to add/change not that much lines of code to make it work with
ozone. On top of that persistent DOM we are using standard Apache Xerces/Xalan.
So I don't know, if it makes sense to try to re-use something.
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@softwarebuero.de
softwarebuero m&b (SMB) http://www.softwarebuero.de