Thomas P. Fuller wrote:
Hi Folks,
I'm doing a bit of research on an idea and hope that you might be able
to save me some time. In particular, if you're able to point us
towards the packages to look at, or point out that this idea is not
worth pursuing (for any reason), we would find your information to be
very helpful.
Here's the idea:
We would like to swap out the internal representation of
table data and replace it with (very table-like) objects that will be
located on a shared memory data grid, such as Oracle Coherence.
We're in the early stages of exploring this idea so we're
not really sure yet if it will work the way we're thinking.
And the question is:
What classes should we look at so that we can virtualise
the database onto a grid memory rather than in-memory or to disk -
implement a iapi.store.access.ConglomerateController maybe?
Thanks in advance for your feedback.
Hi Tom,
I would suggest you re-post to the Apache Derby development list at
[email protected].
You could also have a look at how the in-memory support was added (see
DERBY-646, path derby-646-2b-vfmem_first_rev.diff), and think about
whether your idea goes well with that approach or not.
If you want to do something at a higher level, I think you have to
expect quite a bit of extra work. As an alternative to DERBY-646, you
could also have a look at DERBY-2798. You're not as tightly bound to a
file interface here, but the current proposal doesn't integrate as well
with the existing Derby code.
Regards,
--
Kristian
<https://issues.apache.org/jira/secure/attachment/12401841/derby-646-2b-vfmem_first_rev.diff>
Tom
