robert stephens wrote:
ok, but that wasn't my main point - Please read the rest of my posting enclosed again below!! Specifically please have a look at item --- 3 --- and ***** the real interesting part ***** and let me know if you have any comments on what's going on.....................
Problem Example ---------> For example, I can connect to the example "derbyDB" database from App1 and can connecto to the example "toursDB" from App2 but after disconnecting and quiting both App1 and App2.............App2 is never able to start by itself and connect to the "derbyDB" because "once upon a time" App1 had connected to it even though App1 is no longer running.
I'm doing this on MacOS X so there is a possibility that since they (I think) try to share the JavaVM over multiple apps it could be that the Apple JavaVM was still running.
Also note that I am not doing any of this connecting from the command line but always through one of 2 Java/GUI based apps with App1 being DbVisualizer Free 4.1.1. which is a free Java app you can download from http://www.dbvis.com/products/dbvis/index.html and App2 being Sun Java Studio Creator which is downloadable from Sun at http://wwws.sun.com/software/products/jscreator/
However, I did try the following following to make sure all databases and engines were shut down:
--- 1 --- Using DbVisualizer 4.1.1 made a connection (per the Apache/Derby doc) jdbc:derby:;shutdown=true and jdbc:derby:pathTo_toursDB;shutdown=true
--- 2 --- Re-booted MacOS X to make sure no Apple JavaVM was still running
---3 --- Interesting experiment.......using the command line ij tool (java org.apache.derby.tools.ij) I created a new testdb by doing ij> connect 'jdbc:derby:testdb;create=true';
I verified that Sun Java Studio Creator can connect just fine to this newly created Cloudscape database testdb (and it does just fine) - then I quit this application.
I then connected to testdb with DbVisualizer 4.1.1 and it connects to testdb just fine. I then click the DbVisualizer disconnect button and quit the app.
When I start Sun Java Studio again and try to connect to it again I get a "Can't start database" Error message even after doing all the reboot and jdbc:derby:;shutdown=true stuff above
***** the real interesting part ***** prior to connecting to testdb from ANY app if I save a copy of the testdb/log directory, I am able to get Sun Java Studio to connect to testdb if I swap back in the original testdb/log directory and take out the testdb/log directory that was present when the apps each connnected the first time.
I'm thinking there is some info stored in the testdb/log/log1.dat file that isn't getting cleaned up after disconnect somehow and this is making Sun Java Studio Creator think the testdb (or toursDB) is still open (some file is still open) or locked.
Hi Robert -
Without a doubt there is something odd going on here, your shutdown commands should clear the lock file to allow access by other JVMs. Without the error messages you receive I can only make guesses. Can you get Sun Java Studio to present the the derby exception being thrown? The reason I ask is because of your test with swapping out the logs allows the database to boot. This indicates there may be a recovery problem rather than a dual boot (lock file) problem. The common connect error when multiple JVMs are involved is the dual boot exception that states something to the effect " Another instance of Cloudscape may have already booted the database". From your log swapping test I assume this is not the problem and possibly you have run into a manifestation of the Mac OS X jvm problem described in the article at the following URL: http://www-1.ibm.com/support/docview.wss?rs=636&context=SSCRVP&q1=mac&uid=swg21180506&loc=en_US&cs=utf-8&lang=en
Even if your error message is not the one documented in this article you will need to set the property listed in order to use Derby on Mac OS X with java 1.4.2 .
If this does not resolve the problem please post the exception that Derby throws (possibly recorded in the Java Studio logfile?) - it will indicate the nature of the problem.
