On Windows the Process Explorer tool from Microsoft can be used to determine which file handles are open, and what process is holding them:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx Brett On Thu, Jun 10, 2010 at 6:24 PM, Kristian Waagan <[email protected]>wrote: > On 09.06.10 03:32, oldmhe wrote: > >> >> 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 >> directory manually. >> > > Hi, > > 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. > > > >> Regarding your last question, my program does shutdown explicitly (as >> shown >> in my original post). >> > > Yes, you are shutting down the Derby engine, but not the specific database > explicitly. > An engine shutdown should shut down all booted databases, but it would be > nice to rule out a bug in this area. > > > Regards, > -- > Kristian > > >> 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 >> create tables >> 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) >> exit >> >> With regard to my initial post, Step 4 fails to delete all the files and >> directories (it's able to delete most of them). >> >> However: >> >> 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 >> succeeds. >> >> 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 >> needed. >> >> b) Even if a commit() is needed, the shutdown shouldease all DB >> >> resources (and not hang on to any files). >> >> Any thoughts? >> >> >> Kristian Waagan-4 wrote: >> >>> >>> Hello, >>> >>> 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 >>> database explicitly? >>> (i.e. 'DriverManager.getConnection("jdbc:derby:myDB;shutdown=true");') >>> >>> >>> Regards, >>> -- >>> Kristian >>> >>> >>>> >>>> >>> >>> >>> >> >
