- This topic has 19 replies, 4 voices, and was last updated 20 years, 2 months ago by
.
-
Posts
-
Yes, I agree with you it is now working. Thanks for the select statement it helped to clearify the problem. After I fixed the autocommit problem I only did a subset of my testing and got a misleading result. With the system schemas I only looked into a few of them, and as Murphy would have it the wrong few 🙁 As for my tablespaces, I simply did a quick table create, followed by commit. Two things threw me hear at first
- 1) I was expecting the commit to refresh the navigator tree dynamically. Subsequently I found out the a refresh was required for the update.
2) I appears from my small test that the commit action is not working. When I refresh as per above my new table does show up, however, when I close the connection and reopen it the table is gone. Setting the connection option to “commit on close” fixes this behaviour, but I think it is still a bug that should be explored.There is also the problem that you noticed wherein if the connection is open in the explorer, then it is not possible to run a second JDBC connection against the database. In fact the Network Server seems to get it nickers all in a twist to the extent that it takes a database reboot to straighten it out. At first I thought that this must be a Cloudscape issue, but then I did a simple test. I ran two instances of the junit tests from CaveatEmptor simultaneausly. Each test run simply used different users so the schemas they working against were different. This worked just fine and both tests runs completed successfully. So I am left wondering what could the explorer be doing to hold on to table or database level resources to create lock timeouts. This is rather serious. Would it be possible for you to explor this further and involve the Derby team if you think that it is their problem.
Jeff, thanks for all of your help. At least I have a basically fuctioning DB Explorer for Derby if I simply treat it a bit carefully. Knowing the idiosyncracies helps alot.
– joel
#1 is definitely not the case, but it is not unreasonable to think it would. I will enter an enhancement item for this.
#2 is a new one. I will take a look.
As for Cloudscape connection locking, I get the same behaviour whether accessing from DE or from the command-line. So for example, I start NetworkServer. Then I execute $CLOUDSCAPE_INSTALL/frameworks/embedded/bin/ij.ksh and connect to a test database I created. I leave it connected, and open another cmd-line and run ij. When I try to connect the second time, I get this:
gollum:/usr/local/Cloudscape_10.0# frameworks/embedded/bin/ij.ksh
ij version 10.0 (c) 1997, 2004 IBM Corp.
ij> connect ‘jdbc:cloudscape:testdb’;
ERROR XJ040: Failed to start database ‘testdb’, see the next exception for details.
ERROR XSDB6: Another instance of Cloudscape may have already booted the database /usr/local/Cloudscape_10.0/testdb.I do get the same behavior where the server becomes unusable after connecting from DE, but I am not convinced that DE is at fault here – accessing it using a different jdbc url:
jdbc:cloudscape:net://localhost/testdb
Not sure why this would cause a problem with the server, but I am totally out of my depth on Cloudscape. I leave it to you to follow up with Cloudscape/Derby folks.
[quote]@support-jeff wrote:
#1 is definitely not the case, but it is not unreasonable to think it would. I will enter an enhancement item for this.
Thank you.
@support-jeff wrote:#2 is a new one. I will take a look.
Again, thanks.
@support-jeff wrote:#As for Cloudscape connection locking, I get the same behaviour whether accessing from DE or from the command-line. So for example, I start NetworkServer. Then I execute $CLOUDSCAPE_INSTALL/frameworks/embedded/bin/ij.ksh and connect to a test database I created. I leave it connected, and open another cmd-line and run ij. When I try to connect the second time, I get this:
gollum:/usr/local/Cloudscape_10.0# frameworks/embedded/bin/ij.ksh
ij version 10.0 (c) 1997, 2004 IBM Corp.
ij> connect ‘jdbc:cloudscape:testdb’;
ERROR XJ040: Failed to start database ‘testdb’, see the next exception for details.
ERROR XSDB6: Another instance of Cloudscape may have already booted the database /usr/local/Cloudscape_10.0/testdb.Ah, I think this is the crux of your confusion. Cloudscape is essentially an imbedded database, but it is able to walk and chew gum. The ij.ksh in the embedded directory starts up an embedded instance of the database and allows you to talk to it via the internal JDBC driver. Only one such instance may be created at a time because the instance is reading and writing the database. The message you are getting is telling you the that the active instance has create a lock file. To make a second connection you need to use the DB2Driver. The easiest way for you to make a second connection is to use frameworks/NetworkServer/bin/ij.ksh. This script does not create a database, but uses the DB2Driver to allow you to connect to running database instances. Simply start it up and issue CONNECT ‘url for database’; command to connect. HELP; will print all of the accepted commands.
@support-jeff wrote:I do get the same behavior where the server becomes unusable after connecting from DE, but I am not convinced that DE is at fault here – accessing it using a different jdbc url:
jdbc:cloudscape:net://localhost/testdb
Not sure why this would cause a problem with the server, but I am totally out of my depth on Cloudscape. I leave it to you to follow up with Cloudscape/Derby folks.I would appreciate if you could retry your testing using the DB2Driver for the second connection. I think you will find that there is no problem with doing multiple connects; my testing has demonstrated such. The only time I have seen the lock timeout problem is when DE is involved.
I really think that having support for Derby is going to be a good thing for both the Derby project and for MyEclipse. You may consider it ‘funky’ but is actually a very substantial embedded database. Yes it is missing the slick add ons of many of the other database offering, e.g. there is not even a bin directory for database it self and one has to burrow in example code to even create a database and make a simple connection. On the other hand, I have found it to be elegant to work with once you learn the basics and it appears to be well along the ways to being a enterprise level in quality and capabilities. I hope you appreciate that it is the only open source, non viral database offering that has what it takes to be a serious database, e.g. transaction isolation, JDBC 2 support and the ability to backup the live database.
I have found the Derby dev list to be very cooperative and supportive. I really encourage you to give it a try.
Also, have you looked at the IBM Cloudscape dicumentation. It is an extensive set of PDF documentation including a “Gettting Started”, “Developers Manual”, “Administration Manual”, “Reference Manual” and “Tuning Manual”.
– joel
Ah. Yes, did not understand that using embedded ij meant something different. Did not even see the ij in NetwordServer. I think that the two scripts actually are doing very similar things, since I could connect in either an embedded or network fashion using the one in NetworkServer. Regardless, I can confirm that I am now able to connect multiple times, simultaneously, and the server does not become unstable. Yeah! Thank you for the Cloudscape lessons!
