I am seeing some behavior from Derby that suggests that (a) I have
misunderstood the double-booting prohibitions (b) I do not understand the Derby
nomenclature (c) the default configuration of NetworkServer(ControlImpl) is not
the same as the embedded server (d) there is some odd behavior by Derby or (e)
??? Other ???
Obviously, the odds are 3:1 that I've got something messed up in my head. :-)
Here is what I did (before I knew better):
Created a Java application using Derby as an embedded db server. Worked
nicely.
Class.forName(DRIVER_NAME); // org.apache.derby.jdbc.EmbeddedDriver
StringBuilder urlBuilder = new StringBuilder(CONNECTION_URL_BASE);
urlBuilder.append(databaseName).append(";");
urlBuilder.append("user=").append(username).append(";");
urlBuilder.append("password=").append(password).append(";");
Connection conn = DriverManager.getConnection(
urlBuilder.toString() );
// use conn for the regular JDBC stuff
Thought to myself, "hey, I could let people connect to this application using
crystal (or something) so theat they could design and execute reports against
it".
Added a Network Server to my application (which was already booting Derby in
embedded mode) in its own thread:
// this now occurs *before* the code above, if that is important
server = new NetworkServerControlImpl();
int command = server.parseArgs(dbargs); // dbargs
{"start","-h","127.0.0.1", "-p", "1527"}
server.executeWork(command);
Later, reviewing the Derby Developer's Guide, I found this under the section
"One Derby instance for each Java Virtual Machine":
"You could potentially have two instances of a Derby system (JVM) running on
the same machine at the same time. Each instance must run in a different JVM.
Two separate instances of Derby must not access the same database. For
example, in an embedded environment, an application that accesses Derby
databases starts up the local JDBC driver, which starts up an instance of
Derby. If you start another application, such as ij, and connect to the same
database, severe database corruption can result. See Double-booting system
behavior. "
and this under "Double-booting system behavior":
"Derby attempts to prevent two instances of Derby from booting the same
database by using a file called db.lck inside the database directory.
On all platforms running with a JDK of 1.4 or higher, Derby can successfully
prevent a second instance of Derby from booting the database and thus prevents
corruption. On some platforms running with a JDK lower than 1.4, Derby may
prevent a second instance of Derby from booting the database (previous to JDK
1.4 the ability to do this was OS dependent).
If this is the case, you will see an SQLException like the following:
ERROR XJ040: Failed to start database 'sample', see the next exception for
details.
ERROR XSDB6: Another instance of Derby might have already booted the
databaseC:\databases\sample."
But I do not see this error, and my application appears to "work". So, what
am I missing?
- Is this not two derby instances in the same VM?
- Is this working (but still dangerous) because the
NetworkServerControlImpl doesn't create a db.lck file (I cannot find one)
- Is this not working, but not generating an error message?
- ???? Other ????
Can someone help me understand what I'm doing here? Does this qualify as
double-booting? Should I always being using a regular JDBC driver from within
my app to connect to the NetworkServerControlImpl I create (just any other
out-of-process client would do)?
-chris
