This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
i am studying example with apache openJPA; the reversemapping example i have worked in versions openjpa-1.2.1 and openjap 2.0.0.0-M3 -- both result in same results; the examples directory contains 3 examples -- first 2 do not have any issues; only example 3 -- reversemapping. see the attached build.xml file -- the run/build process calls initialize_db which works; then calls reverse-map-schema; the reverse-map-schema fail with error -- 63 none INFO [exec_null_24] openjpa.Tool - The reverse mapping tool will run on the database. The tool is gathering schema information; this process may take some time. Enable the org.apache.openjpa.jdbc.Schema logging category to see messages about schema data. 173 none INFO [exec_null_24] openjpa.jdbc.JDBC - Using dictionary class "org.apache.openjpa.jdbc.sql.DerbyDictionary". <openjpa-1.2.1-r752877:753278 fatal user error> org.apache.openjpa.util.UserException: A connection could not be obtained for driver class "org.apache.derby.jdbc.EmbeddedDriver" and URL "jdbc:derby:C:\Sun\openJpaPersistenceExamples_1\src2\reversemapping/reversemapping-database;create=true". You may have specified an invalid URL. at org.apache.openjpa.jdbc.schema.DataSourceFactory.newConnectException(DataSourceFactory.java:256) at org.apache.openjpa.jdbc.schema.DataSourceFactory.installDBDictionary(DataSourceFactory.java:242) ..... the program is using Derry EmbeddedDriver -- the db is created locally in the project directory; my experiments show only 1 connection allowed at a time; -- when i create connection in nb68m2 with services/databases/new-connection i can connect -- but only if another connection to the same db does not exist same time. if connected -- builds that attempt to modify the db also fail -- until i disconnect. in this case also there is a db.lck file left in the directory for the database -- which cannot be deleted by netbeans. if i exit netbeans i can delete the db.lck file; it seems as if this db.lck file is the cause for the failure of the reverse-map-schema ant target. if i modify the build.xml so as to separately -- 2 different targets manually invoked -- rather in sequence in the build.xml -- i can get the build to work; -- both initialize_db, and then later reverse-map-schema -- both work. for access to the sample code see: http://openjpa.apache.org/downloads.html
Created attachment 89709 [details] build.xml with targets discussed in writeup
after adding targets to allow separate steps in the build process -- after the initialize_db target is run, the db.lck file remains. it automatically goes away if i exit netbeans after restarting netbeans -- 6.8M2 then i can run the other targets necessary to complete the build. and run the code.
I think the problem is in scripts. They probably do not close DB connection. Either do not use embedded driver or fix your scripts to properly close connectioin. I tried to create a connection with embedded driver in NetBeans IDE. If I am connected, file C:\Users\myhome\.netbeans-derby\testdb\db.lck exists. If I disconnect, the file disappears. This behaviour is expected. If you find some wrong use case related to NetBeans IDE, feel free to reopen.
you did less to research this problem than i did; i did exactly the same thing as you - and more. i did not write the scripts; and i provided the scripts for you to look at. there is nothing in the scripts that open or close the connection -- they are ant targets for the ant program. the scripts come from openjpp.apache.org and have been around for years -- presumably if they didnt work someone would have noticed by now. the difference is i am executing the build.xml with netbeans -- not a command line ant. perhaps the bug is in ant; netbeans is keeping the connection open after the build.xml exits. time permitting i will test with command line ant -- these are example provided by openjpa.apache.org -- the EmbeddedDriver is a requirement for these examples. the initialize_db target is short/small -- see below -- since you apparantly didnt study the info i provided before, <target name="initialize-db" unless="initialize-db-skip" description="Drop then re-create the database"> <!-- first make sure the database is empty --> <sql src="schema/dropdb.sql" driver="${dbdriver}" url="${dburl}" userid="${dbuser}" password="${dbpass}" onerror="continue" classpathref="classpath"/> <!-- build the database --> <sql driver="${dbdriver}" url="${dburl}" userid="${dbuser}" password="${dbpass}" classpathref="classpath"> <transaction src="schema/ToursDB_schema.sql"/> <transaction src="schema/loadCOUNTRIES.sql"/> <transaction src="schema/loadCITIES.sql"/> <transaction src="schema/loadAIRLINES.sql"/> <transaction src="schema/loadFLIGHTS1.sql"/> <transaction src="schema/loadFLIGHTS2.sql"/> <transaction src="schema/loadFLIGHTAVAILABILITY1.sql"/> <transaction src="schema/loadFLIGHTAVAILABILITY2.sql"/> </sql> </target> this 1 target will leave the database connection open.
i have researched more -- the db.lck file remains with standalone ant invocation -- but the file can be deleted after the script is run; when the 2 targets are invoked in sequence in build.xml an error occurs -- prob due to the db.lck file. now to try and determine if win7, ant 1.7.1, or derby bug; the file should be created by derby so seems should be a derby bug -- but how could the code have been shipped if a bug in derby?
more research -- i asked the openjpa mailing list for info also. the db.lck file apparently doesnt really matter; cmd line ant invocations will continue to work -- multiple invocations of target initialize-db succeed -- even though db.lck remains after each invocation. also the db.lck file is deletable -- if i try to delete it i can; but initialize-db works even if not deleted. in nb68MN2 -- the file is locked/open -- ie -- it cannot be deleted until netbeans exits 1st. so this seems like a bug ? separate from the issue i have pending with openjpa mailing list.
For me it seems like a bug in JavaDB. It writes to db.lck and doesn't release it. All ant scripts in NetBeans are run in the same JVM, so next attempt to access db.lck fails and the exception is thrown. In contrary if you run from command line, it starts everytime a new JVM instance and all resources are released when it finishes. That's why it never throws any exception with one sql target. We cannot fix it in NetBeans. It should be fixed in JavaDB. Again I recommend to use network driver instead of embedded. You wrote it is a requirement for these examples but it should be enough to just pass ${dbdriver}, ${dburl}, ${dbuser}, ${dbpass} properties with new values.
are you saying the db.lck file cannot be deleted because something caused by derby in the JVM which is still also running netbeans -- is keeping the file db.lck locked somehow -- NOTE: the file cannot be deleted by hand or from cmd line until netbeans exits ?
Yes, exactly as you summarized.
when the 3 examples are run -- especially the reversemapping example -- there is not db.lck file left. what about the possibility the ant implementation of the sql target is not closing the connection? would that be a netbeans bug -- or would netbeans look an ant bug?
Previously, I looked at ant's sources and connection was always closed when the sql target was about to finish.
all the openjpa examples, and derby examples i have been testing -- all work repeatedly, ant dont leave db.lck file leftover afterwards. yes -- each invocation involves a separate jvm -- but no leftover db.lck file?