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

Re: Fwd: Re: XML and JNDI

I agree that first version of Ozone-XML can be without clustering of DOM nodes,
but for long term I prefer clustering or paging of DOM nodes (like in IPSI PDOM),
otherwise traversing of PDOM nodes from the client will cause a network overhead
(like in Ozone Garage oldtimers example).

Is there any references/links to Common DOM Query API (CDQA) ?

Falko Braeutigam wrote:

> > > I think this is not was Steve was saying. Of course, the DOM nodes will be
> > > stored independently as OzoneObjects. The problem may be the overhead of the
> > > database when storing small objects (like DOM nodes). To avoid this I was
> > > thinking about clustering of nodes. Actually, Steve do not want such tricky
> > > things. He want each node to be stored as an independent database object. So,
> > > you are of the same opinion. Right?
> >
> > Yes, Falko, that's what I meant.  By whatever means, the entire DOM
> > would be on disk
> > whether it be in the database or layered over it.  The storage overhead
> > might be large,
> > but it would just be disk space, and the low cost of that is only likely
> > to go
> > down further, and it's already pretty low (in the U.S. we are at <$700
> > for an 18G
> > U2W scsi drive).
> >
> > In the GMD-IPSI XQL+PDOM, you just query the dataset as though it were
> > an in-memory
> > DOM, even though the whole thing is on disk.  T
> This should be possible also with ozone. In fact, this is the way to
> communicate with the database - just calling methods of proxy objects that act
> like the real object in the database.
>
> > The XQL result set is
> > returned as an
> > in-memory object.  I don't know if the PDOM implementation caches any
> > nodes in memory;
> > one could imagine that being a useful optimization, but unnecessary for
> > an initial
> > release or two.
> Caching is already there in ozone.
>
> > The PDOM uses indexing to speed disk access.
> Unfortunately, DOM does not provide data access paths than the NameNodeMap. So
> if indexing or other things are needed, it should go in the Common DOM Query
> API (CDQA) layer on top of DOM. I do not know exactly what's going on in this
> layer but Vincent has nearly finished his work on CDQA. He did a lot of
> research querying semi-structured data. But CDQA is based on pure DOM. This
> seems to be a good architecture. (?)
>
> > I can see that if there is significant database overhead clustering
> > would be a gain,
> > but again one could do it later, no?
> I think so.
>
> Falko
> --
> ______________________________________________________________________
> Falko Braeutigam                        mailto:falko@softwarebuero.de
> softwarebuero m&b (SMB)                   http://www.softwarebuero.de

--
-------------------------------------------------
Zvi Avraham, Senior Software Engineer
NetManage Inc., Visual Connectivity Division
http://www.netmanage.com/products/visual_conn.asp


begin:vcard 
n:Avraham;Zvi
tel;cell:+972-52-837908
tel;fax:+972-3-5788752
tel;home:+972-4-8551158
tel;work:+972-3-5788753
x-mozilla-html:FALSE
url:http://www2.netmanage.co.il/~zvia
org:NetManage, Inc.;Visual Connectivity Division<BR><A href="/ozone-users/1999/http://www.netmanage.com"><IMG src="http://www.netmanage.com/images/newhead-l.gif" WIDTH="129" HEIGHT="63" ALT="NetManage" BORDER="0"></A><A href='http://www.netmanage.com/products/visual_conn.asp'><IMG src='http://www.netmanage.com/images/vc_middle.gif' WIDTH=227 HEIGHT=63 ALT='NetManage Visual Connectivity Group' border=0></A>
adr:;;;;;;
version:2.1
email;internet:zvia@netmanage.co.il
title:Senior Software Engineer
note:I beleive I can fly !
fn:Zvi Avraham
end:vcard