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