On Windows the Process Explorer tool from Microsoft can be used to determine which file handles are open, and what process is holding them:
On 09.06.10 03:32, oldmhe wrote:Hi,
The OS is Windows XP.
Since I'm using the embedded driver, I don't think it's possible to check
what process is hanging on to the file. I.e., I believe it's the same
process as my program. When my program exits, I'm able to delete the
It would still be useful to see which files the process has open handles to. If there is no tool readily available for doing this, a crude way would be to run the partly successful delete and then just post a listing of the files that are left in the database directories.Yes, you are shutting down the Derby engine, but not the specific database explicitly.
Regarding your last question, my program does shutdown explicitly (as shown
in my original post).
An engine shutdown should shut down all booted databases, but it would be nice to rule out a bug in this area.
b) Even if a commit() is needed, the shutdown shouldease all DB
Since posting, I found a solution, but I don't understand why it works.
Below is a simplification of what the program does:
1. load the embedded driver
set AutoCommit to false
connect to the DB engine, and create a DB
load the tables with data, and commit all work
2. using SELECT, read some data records, and create an output file.
3. shutdown the DB engine
4. try to delete the DB directory (and all files and subdirectories)
With regard to my initial post, Step 4 fails to delete all the files and
directories (it's able to delete most of them).
1. If I omit Step 2 (the reading of the DB), Step 4 succeeds.
2. Or, if I add "xxx.commit()" between Step 2 and Step 3, then Step 4
It seems that a commit() is needed even though Step 2 makes no change to the
DB. This is contrary to my expectations for two reasons:
a) Since Step 2 is a read-only operation, I don't see why commit() is
resources (and not hang on to any files).
Kristian Waagan-4 wrote:
What operating system are you using?
Are you able to use the operation system's proper tool to check which
process (if any) is hanging on to the file?
(i.e. pfiles or lsof)
Also, do you see the same behavior if you in addition shut down the