Øystein Grøvlen wrote:

> [snip]
>
>In the Derby TODO-list it says that your prototype is an
>"implementation of the org.apache.derby.io package that provides an
>in-memory database".  Does that mean that the Raw Store (e.g.
>RAFContainer) thinks that it is writing to a file, but that the
>io-system is basically doing dummy operations? That does not sound
>very efficient to me compared to supporting the in-memory database
>directly at the Raw Store level.
>
>I would except an in-memory implementation to have in-memory specific
>implementations of for example Logger and BaseContainer, but I can see
>that that is probably much more work.  Is that the main reason for
>doing it this way?
>
>  
>
Yes, in my prototype the Raw Store thinks that it is writing to a file. 
(Actually it thinks that it is writing to the StorageFactory and related 
interfaces). The raw store is unchanged from the one in the normal Derby 
implementation. The prototype was originally written to test the 
StorageFactory interface and the Raw Store's use of it.

As you guessed, the reason for doing it this way is to reduce the amount 
of work required. We only have one version of the Raw Store to 
implement, test, and maintain. Furthermore, we can plug in other 
StorageFactory implementations beyond simple disk file or memory 
implementations.

It is the usual trade-off with program modularization: you make it 
easier to plug in new components, but make some optimizations difficult 
or impossible.

Jack Klebanoff