db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Fitch <0519...@acadiau.ca>
Subject Re: [jira] Created: (DERBY-646) In-memory backend storage support
Date Mon, 31 Oct 2005 14:20:32 GMT
Øystein Grøvlen wrote:
>>>>>>"SF" == Stephen Fitch <051933f@acadiau.ca> writes:
> 
> 
>     SF> Hi Mike,
>     SF> the issue I'm having is I can't  find a way to tell the network server
>     SF> what StorageFactory to use from the network client driver.
> 
> 
>     SF> On the  embedded side  of things, I  just define a  new subsubprotocol
>     SF> when I start java with:
> 
>     SF> -Dderby.subSubProtocol.memory=org.apache.derby.impl.io.MemoryStorageFactory
>     SF> (alternatively I can change some of the engine code and register it as
>     SF> a persistent service which results in the same issue)
> 
> I am a bit confused about why the use of StorageFactory is decided
> when opening a connection.  

When you open a connection, derby attempts to boot the database (if it 
exists) or creates a new one if specified. The StorageFactory needs to 
be determined before any creation or access to the "StorageFile"s the 
database is stored on.

>Will it be possible for different
> connections to use different StorageFactory within the same system?

My understanding is there's one StorageFactory per database, and all 
connections to that database use that StorageFactory.

> I guess different StorageFactory within the same database is not
> possible.  

Not really with the current design as far as I can tell :/.

I think the current design allows for a different StorageFactory 
instance to be used for logs residing in a different directory than the 
default. I'm planning to look at allowing the database to be in-memory 
but logging to disk.

I'm also going to make my in-memory implementation automatically(?) 
import a database from disk into memory if it already exists.

>In that case, why not make it a parameter when creating the
> database?

I'd like to be able to import existing disk-based databases. So, rather 
than specifying it when we create the database, we specify it when 
booting the database.

Something like:
jdbc:derby:test;storageFactory=memory
jdbc:derby://host:port/test;storageFactory=memory

It could coded dynamically like the current embedded client's syntax 
(jdbc:derby:[storagefactory:]<database>;attributes). This way you can 
specify whatever StorageFactory you want even if it's not part of derby.




Stephen Fitch
Acadia University






Mime
View raw message