db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein.Grov...@sun.com (Øystein Grøvlen)
Subject Re: In-memory database
Date Wed, 06 Apr 2005 08:32:46 GMT
>>>>> "JK" == Jack Klebanoff <klebanoff-derby@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

View raw message