Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <588991833.1235063642504.JavaMail.jira@brutus>
Date: Thu, 19 Feb 2009 09:14:02 -0800 (PST)
From: "Kristian Waagan (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-646) In-memory backend storage support
In-Reply-To: <1527660289.1130261635642.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kristian Waagan updated DERBY-646:
----------------------------------

    Attachment: derby-646-2a-vfmem_first_rev.diff
                derby-646-2a-vfmem_first_rev.stat

The patch 'derby-646-2a-vfmem_first_rev.diff' is the first revision of an in-memory backend for Derby.

The implementation takes the same general approach as the original patch contributed by Stephen Fitch, but it is implemented from scratch.
This was a choice I made because the state of the original patch was unknown, and I wanted to learn more about the internals of Derby in this area.

Since this is the first revision, there are limitations;
 o The maximum "file size" is 256 MB, 512 MB or 2 GB depending on the page size used.
    The system tries to make the blocks used to store data the same size as the pages used by Derby. When the page size is "indeterminable", 4 KB is used by default.
    If you hit the 256 MB limit, you have two options; set the page size to 32 KB, or modify BlockedByteArray.
    I think that either the max size should be configurable via properties, or the BlockedByteArray should be extended with a better growth functionality. This is basically a tradeoff between memory usage for smaller files, and CPU usage (copying bytes). As an alternative, I think one can avoid both excessive memory overhead and byte copying by adding complexity :)
 o The in-memory backend is not enabled for the client driver.
    I haven't investigated this, but if you want to test with the client driver, replace the storage factory class for PersistentStorage.DIRECTORY in BaseMonitor with the VFMemoryStoreageFactory.
    This will make the in-memory backend the default backend, and *none* of you databases will be persisted.
    I think some handling code in the client driver has to be added to make the in-memory backend available there.
 o There is no easy way to delete a database, except for restarting the JVM.
    If this is a problem for your usage, there is a purgeDatabase-method in the storage factory (a database is currently named by an absolute file path in the storage factory).

[How to test]
 1) Download the patch (2a), apply it and build Derby.
 2) Connect to a database using the following prefix in the JDBC connection url: "jdbc:derby:mem" (remember to create the database the first time you connect to it).


WARNING: I have only tested this on OpenSolaris. It would be nice if someone running Windows could take the patch for a test-spin.
I'm sure there are more limitations and problems, but I'd like to get this out in the community as soon as possible. I have managed to run most of the existing regression tests with the patch, so it should be usable.

Feedback is welcome. 

> In-memory backend storage support
> ---------------------------------
>
>                 Key: DERBY-646
>                 URL: https://issues.apache.org/jira/browse/DERBY-646
>             Project: Derby
>          Issue Type: New Feature
>          Components: Store
>         Environment: All
>            Reporter: Stephen Fitch
>         Attachments: derby-646-1a-raw-compiles.diff, derby-646-1a-raw-compiles.stat, derby-646-2a-vfmem_first_rev.diff, derby-646-2a-vfmem_first_rev.stat, svn.diff
>
>
> To allow creation and modification of databases in-memory without requiring disk access or space to store the database.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.