db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-646) In-memory backend storage support
Date Thu, 19 Feb 2009 17:14:02 GMT

     [ 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.


Mime
View raw message