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 Wed, 02 Nov 2005 20:04:42 GMT
Øystein Grøvlen wrote:
>>>>>>"SF" == Stephen Fitch <051933f@acadiau.ca> writes:
>     SF> Øystein Grøvlen wrote:
>     >> What happens if one when connecting specifies another StorageFactory
>     >> than the one currently in use?
>     SF> Looks like Derby detects there  is already a StorageFactory in use for
>     SF> that directory and database name. It uses the existing one rather than
>     SF> the specified one even if the specified one is different.
> I would have been good to get an exception if one explicitly specify
> another StorageFactory.  (Connecting without specifying StorageFactory
> should just use whatever has been booted.)

I just ran a test with a clean version of the trunk code plus my new 
in-memory code. With the jdbc:derby:[storagefactory]:dbname syntax, 
derby will open the specified StorageFactory. This is probably because 
it passes around memory:dbname as the database name. So when it checks 
to see if there's a StorageFactory in use, it doesn't find it because 
the database will be listed under alternatesubSubProtocol:dbname or just 
dbname for the default StorageFactory.

If I create a database with the name "testSF" in /home/derby under 
DirStorageFactory then another under a different WritableStorageFactory, 
they will end up competing for the same directories. For example, my 
in-memory implementation still needs to use the on disk tmp directory.

So how about this...

1. Only one StorageFactory for a given directory and database name can 
be used at a time

2. If a StorageFactory exists and a connection is attempted specifying a 
different StorageFactory, an exception will be thrown

 > Øystein Grøvlen:
 > (Connecting without specifying StorageFactory
 > should just use whatever has been booted.)
3. If a StorageFactory exists and a connection is attempted WITHOUT 
specifying a StorageFactory, and the StorageFactory in use is NOT the 
default (DirStorageFactory), throw an Exception.  I think this would be 
preferred behavior because if you connected with just jdbc:derby:dbname 
you would assume it would be using the default StorageFactory.

4. We can adopt an alternate method of specifying a StorageFactory with 
an atrribute.  This will make it usable on any driver. Attached is a 
simple example patch that should do the job. With this patch, the 
jdbc:derby:storagefactory:dbname;storageFactory=sfname syntax will 
ignore sfname attribute if a storagefactory name is specified before the 
database name.


Stephen Fitch
Acadia University

View raw message