[jira] Commented: (DERBY-646) In-memory backend storage support

["Kristian Waagan (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678800#action_12678800 ] 

Kristian Waagan commented on DERBY-646:
---------------------------------------

According to the 10.5 release page on the Wiki, the 10.5 branch will be
created 2008-03-16. This leaves very little time to work on the
in-memory back end. I'm describing my plan for this user-requested
feature below. Most of the elements of the plan originates from the
comments on this Jira issue.

** Patch status
The community has three patches available;
 A) derby-646-20090222.diff
 B) derby-646-2a-vfmem_first_rev.diff
 C) svn.diff

Patch C is the original patch from Stephen Fitch. It was uploaded in
March 2006. It is writing the database log to disk. The general state is
not very well known, but I believe it is not quite "production ready"
int it's current form. The patch demonstrates the overall approach,
which is also used by the two other patches. I can't speak for A, but B
is more or less a re-implementation of C. This follows from the
interfaces that have to be implemented.
Stephen Fitch has a CLA on file.

Patch A is from Cheng Che Chen, which has written a solution of his own.
The solution passes basic ad-hoc testing, and has been successfully used
in several of the performance tests in the Derby code repository.
This solution seems to be the most feature rich one, and it also has a
functional test.
Cheng Che Chen has a CLA on file.

Patch B is from Kristian Waagan. The test has passed ad-hoc testing, and
has been successfully used in several of the performance tests in the
Derby code repository. The main difference from patch A, is that it
seems to perform better on CMT machines.
The solution is able to run most of suites.All without failures.
Kristian Waagan has a CLA on file.


** Plan
 1) Commit patch B.
    (reasons: CMT performance, size, readability)
 2) Work on the committed code, addressing the TODOs.
 3) Incorporate tests from patch A and some additional tests.
    (additional tests: backup in-mem then restore/re-boot with directory
    (default) storage engine, simple boot/create test)
 4) Incorporate features from patch A.
    (persist to disk on exit/shutdown, restore from disk on boot,
    finalizer, more?)
 5) Figure out what to do on OOME (if anything).
 6) General testing and improvements.
 7) Documentation.

I hope to address at least steps 1-3 before the branch is cut.
It is not clear to me whether an in-memory back end will be a documented
and supported feature of 10.5. I like the idea of providing it as-is
without any documentation in 10.5, and then solidify it in 10.6.
In the meantime, interested users can try it out and give us feedback,
and the community can continue to test and improve the feature.

Unless someone objects, I will commit the patch on Monday.
I would also like to invite those who plan to contribute actively on the
feature to let the community know. Feel free to flesh out the details of
the plan.

Finally, a great thank you to both Stephen Fitch and Cheng Che Chen for
contributing their work to the Derby community! I hope continued
contribution is of interest :)
I would be very happy if Cheng could spare some time to get some of his
more advanced features into the Derby code line.

> 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-20090222.diff, derby-646-20090222.stat, derby-646-2a-vfmem_first_rev.diff, derby-646-2a-vfmem_first_rev.stat, derby-646-performance_comparison_1a.txt, 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.