Øystein Grøvlen wrote:
"SF" == Stephen Fitch <[EMAIL PROTECTED]> 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





Reply via email to