Øystein Grøvlen wrote:
"SF" == Stephen Fitch <[EMAIL PROTECTED]> 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.
Opinions?
Stephen Fitch
Acadia University
Index: java/engine/org/apache/derby/iapi/reference/Attribute.java
===================================================================
--- java/engine/org/apache/derby/iapi/reference/Attribute.java (revision
330257)
+++ java/engine/org/apache/derby/iapi/reference/Attribute.java (working copy)
@@ -197,6 +197,11 @@
The attribute that is used to request a roll-forward recovery
of the database.
*/
String ROLL_FORWARD_RECOVERY_FROM = "rollForwardRecoveryFrom";
+
+ /**
+ * The attribute that requests use of a different StorageFactory
+ */
+ String STORAGEFACTORY = "storageFactory";
}
Index: java/engine/org/apache/derby/jdbc/InternalDriver.java
===================================================================
--- java/engine/org/apache/derby/jdbc/InternalDriver.java (revision
330257)
+++ java/engine/org/apache/derby/jdbc/InternalDriver.java (working copy)
@@ -350,7 +350,10 @@
// Beetle 4653 - trim database name to remove blanks that might
make a difference on finding the database
// on unix platforms
dbname = dbname.trim();
-
+ String sf = info.getProperty(Attribute.STORAGEFACTORY);
+ if (sf != null && dbname.indexOf(":") == -1) {
+ dbname = sf + ":" + dbname;
+ }
return dbname;
}
