db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Goodacre <cgooda...@yahoo.com>
Subject Double-booting Derby
Date Mon, 31 Aug 2009 17:45:33 GMT
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

Mime
View raw message