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
Øystein


Mime
View raw message