[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Looking for a good PDOM
On Mon, 17 Apr 2000, Marcel Ruff wrote:
> Falko Braeutigam wrote:
> >
> > On Mon, 17 Apr 2000, you wrote:
> > > Hi,
> > >
> > > we are looking for a free persistent DOM implementation.
> > ozone/XML is 100% Java
> Good.
>
> > > The PDOM should cache parts of the DOM tree to/from harddisk
> > > transparently, so that the XPath/XSLT engine doesn't notice it.
> > ozone works this way (not only for DOM objects, btw ;)
> Even better.
>
> >
> > >
> > > Here is our wish list :-)
> > >
> > > - Free for commercials as well (like LGPL or similar)
> > the ozone public APIs are under LGPL. The DOM code that we are currenly using
> > is a port of OpenXML which is ok for commercial use too.
> Excellent.
>
> >
> > >
> > > - Allowing to use any XSL engine (we use currently XT from J.Clark
> > > to query the DOM with XPath, since it is the fastest engine)
> > We have tried Lotus and Xalan without problems. It should work also with XT.
> Good.
>
> >
> > >
> > > - Should work non validated as well (no dtd, since the DOM is generic).
> > ozone/XML basically provides the persistent DOM. It can be used with any parser.
> ?
>
>
> > > Could ozone be a solution for this?
> > Yes, I think so. BUT, since ozone/XML is based on the general purpose OODBMS
> > it is not as fast as deticated XML storage solutions, yet ;) (see the excelon
> > comparison thread) And the programming must follow ozone programming rules.
> > This means any DOM query and manipulation should be done on the server for
> > performance reasons.
> Yes, the same with us. XPath queries are passed by CORBA or http or
> whatever
> and run on the server.
When I say 'server' I mean the database server not the application server.
>
> Is it possible to extract only the PDOM code from ozone
> without any RMI or whatever as we look for maximum speed?
NOOOooooOOOOOoooooOOOOOO!!! This is not possible. (sorry ;) but I've answered
this questions 100 times before; but I understand that the lack of documentation
leads to such questions again and again)
The proxy mechanism is an inherent part of the ozone architecture. Yes, we also
use this to communicate between client and server but this is not the
primarly reason to use proxies.
ozone extends the Java object model by transactions and persistency. The goal
is to do this as transparently as possible to the programmer. To reach this
goal we needed a technology to get control between the single method calls of
the (database) objects to do our transaction and persistency stuff. We decided
to use self generated proxies. As you see, if you take away this stuff nothing
is left from ozone.
The use of proxies give ozone the possibility to *transparently* activate
parts of the objects graph (DOM tree) that are needed, to *transparently* check
access rights and transaction isolation - If you need this feature then you
need proxies, if you don't need this then you don't need ozone.
>
> Is the performance degraded, even when everything fits into memory?
> This is important for us, since most time the DOM fits into RAM.
Yes, it's somewhat slow in some cases. The above mentioned transparency has its
price! However, you need to check in your actual environment if it meets your
needs.
>
> Can we choose an arbitrary XML parser and ozone persitency plugs in?
Hmmm... To one of your questions I answered: "ozone/XML basically provides the
persistent DOM. It can be used with any parser.". And you were ?. IMO this is
the answer, not?
> Now we use Sun XML parser and enjoy some nonestandard api calls
> (especially to merge two DOM trees into on). This we would need
> to code self if ozone DOM doesn't like it (and could be much
> slower than the Sun internal merge).
Maybe a guy who is more familiar with the XML stuff can answer this question?
Lars?
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@softwarebuero.de
softwarebuero m&b (SMB) http://www.softwarebuero.de