Apache DB question

["Thomas P. Fuller" <th...@yahoo.ie>]

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.

Tom

Re: Apache DB question

[Kristian Waagan <Kr...@Sun.COM>]

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 
derby-dev@db.apache.org.
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
>