While we are discussing B-Trees and transactions let me make an additional point. B-Trees are optimized for disk I/O performance. It seems to me the way to go is to create an in-memory representation of the database using a different data structure that performs better. We could then add transaction support that would physically write the data from memory to disk in a B-Tree. For people who are much interested in a robust data store then can configure Xindice to auto-commit every transaction, so the in-memory image is always in sync with the disk image. And for those of us who can slack off on the robustness in exchange for a large performance gain, we can control when and how the transactions are committed.
Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -----Original Message----- > From: Kurt Ward [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 05, 2002 8:09 AM > To: [EMAIL PROTECTED] > Subject: Re: [2.0] Shaking up the tree > > ----- Original Message ----- > From: "James Bates" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, December 05, 2002 5:52 AM > Subject: RE: [2.0] Shaking up the tree > > > > I think the current names are fine actually... the server contains only > server code, core contains > > the database whether used by a server, or directly by the embed driver, > and client contains > > code to -generically access the server, and package this server access > through XML:DB or possibly other means (tb determined later)... > > > > As for the embed driver, it allows embedded access to Xindice, it seems > right to me also. > > I agree with James on the current names. > > > I would however wish to look at optimizing some of the internal > workings. > > > > For example: > > > > 1) there's a complete B-Tree implementation, and XML documents are in > fact > trees, but are stored simply as byte arrays... Why not store NODES in the > B-Tree, allowing much more clever indexing > > > > 2) Xindice internally handles all XUpdates, Queries, everything by > completely loading an XML document into an in-core DOM object model. > Storing > nodes in stead of documents would also allow this to be far more > optimized. > In particular, XUpdate's could TRULY update the db, in stead of reading a > DOM, modifying and writing a complete document back. > > > > 3) Introduce some transaction and failover support; don't know where > yet: > the pages of the Paged >file? complete B-Tree's ? documents in > collections? > > This makes sense to me, but I know nothing about B-Tree :-) I'll take a > look at the internals documentation that you have been working on and try > to > familiarize myself with the way Xindice performs things on the core level. > Then maybe I can help out. > > Kurt
