Re: In-memory database

[Øystein Grøvlen <Oy...@sun.com>]

>>>>> "JK" == Jack Klebanoff <kl...@sbcglobal.net> writes:

    JK> Richard Boehme wrote:
    >> Hi there. My application will be  building a database from a part of
    >> the file system on launch, so that file system changes can alter the
    >> application.  I was  thinking of  using an  in-memory  database. The
    >> "DerbyToDo" page on incubator.apache.org  has this feature listed as
    >> "Prototype  code". Does  anyone know  when this  might be  more than
    >> prototype code?

    >> 
    >> Thanks.
    >> 
    >> Richard
    >> 
    >> 
    JK> Sorry, but I am working on other things now. So it is on the back burner.

    JK> Part of  the problem is that  it is IBM proprietary  code. My manager,
    JK> Dan Debrunner,  wants to contribute it  to Apache. I  don't think that
    JK> anyone at IBM would object to contributing it. However, IBM has a time
    JK> consuming process  that we must  follow for contributing code  to open
    JK> source.

In the Derby TODO-list it says that your prototype is an
"implementation of the org.apache.derby.io package that provides an
in-memory database".  Does that mean that the Raw Store (e.g.
RAFContainer) thinks that it is writing to a file, but that the
io-system is basically doing dummy operations? That does not sound
very efficient to me compared to supporting the in-memory database
directly at the Raw Store level.

I would except an in-memory implementation to have in-memory specific
implementations of for example Logger and BaseContainer, but I can see
that that is probably much more work.  Is that the main reason for
doing it this way?

-- 
Øystein Grøvlen, Senior Staff Engineer
Sun Microsystems, Database Technology Group
Trondheim, Norway
Øystein

Re: In-memory database

[Jack Klebanoff <kl...@sbcglobal.net>]

Øystein Grøvlen wrote:

> [snip]
>
>In the Derby TODO-list it says that your prototype is an
>"implementation of the org.apache.derby.io package that provides an
>in-memory database".  Does that mean that the Raw Store (e.g.
>RAFContainer) thinks that it is writing to a file, but that the
>io-system is basically doing dummy operations? That does not sound
>very efficient to me compared to supporting the in-memory database
>directly at the Raw Store level.
>
>I would except an in-memory implementation to have in-memory specific
>implementations of for example Logger and BaseContainer, but I can see
>that that is probably much more work.  Is that the main reason for
>doing it this way?
>
>  
>
Yes, in my prototype the Raw Store thinks that it is writing to a file. 
(Actually it thinks that it is writing to the StorageFactory and related 
interfaces). The raw store is unchanged from the one in the normal Derby 
implementation. The prototype was originally written to test the 
StorageFactory interface and the Raw Store's use of it.

As you guessed, the reason for doing it this way is to reduce the amount 
of work required. We only have one version of the Raw Store to 
implement, test, and maintain. Furthermore, we can plug in other 
StorageFactory implementations beyond simple disk file or memory 
implementations.

It is the usual trade-off with program modularization: you make it 
easier to plug in new components, but make some optimizations difficult 
or impossible.

Jack Klebanoff

DITA docs & conrefs & xalan & ant & ...

[Fred Baube <fr...@metadoc.fi>]

Thanks to all for help with previous questions. Here's another :)

I'm generating the PDF's in a servlet, using stylesheets 
straight from DITAOT-1.0, and Xalan.  I'm finding that 
many parameters are missing from the final output. For 
example, in adminguide/"Purpose of this Guide":

	This guide explains how to use in a multiple-client 
	environment. It also provides information that a 
	server administrator might need to keep running 
	with high performance and reliability in a server 
	framework or a multiple-client application server. 
	(When running in embedded mode, databases typically 
	do not need any administration.)

If I examine the source, I find that the XML element

	<ph conref="adminconrefs.dita#prod/productshortname"/>

has not been replaced.  It and many other properties are
defined in adminconrefs.dita .  

So, my Xalan environment in my servlet is not successfully 
resolving these conref's.  What am I missing ?  An argument 
to Xalan ?  A stylesheet specific to Derby ?  A quick look
at the "make pdf" target does not reveal any clues. 


thanks,

fred baube