You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by oldmhe <mh...@yahoo.com> on 2010/06/04 18:51:10 UTC
can't delete my DB directory
Prior to exiting, my Java program issues a shutdown, and then tries to delete
the DB directory (recursively), but is not able to completely delete the
directory. Here's the code:
try {
DriverManager.getConnection("jdbc:derby:;shutdown=true");
} catch (SQLException eSQLException) {
if (
eSQLException.getErrorCode() == 50000
&&
"XJ015".equals(eSQLException.getSQLState())
) {
// successful shutdown
} else
printSQLException(eSQLException);
}
removeDir(new File(dbnmString)); // remove DB directory
(removeDir is my own function)
If removeDir() is called before connecting to the DB, it works fine. But
the above call to removeDir() only deletes some of the files and directories
within dbnmString -- as if Derby is still accessing them (or has not closed
them).
I also tried dropping the DB just before the shutdown code, with the same
results.
Any ideas would be appreciated.
--
View this message in context: http://old.nabble.com/can%27t-delete-my-DB-directory-tp28782490p28782490.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: can't delete my DB directory
Posted by Brett Wooldridge <br...@gmail.com>.
AFAIK, when auto-commit is off, transaction demarcation is left (almost)
entirely to the user. You should commit() the connection, or close() any
Statements/ResultSets. What a database does to handle "unfinished"
transactions (even read-only ones) at shutdown is likely highly DB-specific
and not part of the spec. While I think Derby should not hang or leave open
resources after shutdown, I wouldn't count on it.
In the same way that an OS will usually close all open file handles owned by
a process when that process exits, it is better if your program cleans up
after itself and closes resources explicitly rather than relying on some
implicit behavior.
In that vein, given that you have turned auto-commit off, the last thing
your program should do before shutdown is commit() or rollback(). In
auto-commit mode, the end of one transaction implies the beginning of the
next. So if you've run *any* SQL on a connection, that connection should be
rolled back or committed at some point.
-Brett
On Thu, Jun 10, 2010 at 3:48 PM, oldmhe <mh...@yahoo.com> wrote:
>
> Thanks for the info.
>
> Though this is my first Java DB program. I've written many C programs
> using
> ESQL, and have never needed to issue a commit after a read or query
> operation.
>
> Is this "commit after query" requirement an SQL concept, or is it just
> related to the Java JDBC API?
>
>
> Brett Wooldridge-2 wrote:
> >
> > Even read operations create transactions (and locks). Because you set
> > autocommit to false, you must manually commit.
> >
> > Having said that, I would expect shutdown to automatically rollback
> > any open transactions at the time of shutdown.
> >
> > Brett
> >
> > Sent from my iPhone
> >
> > On Jun 9, 2010, at 10:32, oldmhe <mh...@yahoo.com> 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.
> >>
> >> Regarding your last question, my program does shutdown explicitly
> >> (as shown
> >> in my original post).
> >>
> >> 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 should release 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
> >>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> View this message in context:
> >>
> http://old.nabble.com/can%27t-delete-my-DB-directory-tp28782490p28825037.html
> >> Sent from the Apache Derby Users mailing list archive at Nabble.com.
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/can%27t-delete-my-DB-directory-tp28782490p28839396.html
> Sent from the Apache Derby Users mailing list archive at Nabble.com.
>
>
Re: can't delete my DB directory
Posted by oldmhe <mh...@yahoo.com>.
Thanks for the info.
Though this is my first Java DB program. I've written many C programs using
ESQL, and have never needed to issue a commit after a read or query
operation.
Is this "commit after query" requirement an SQL concept, or is it just
related to the Java JDBC API?
Brett Wooldridge-2 wrote:
>
> Even read operations create transactions (and locks). Because you set
> autocommit to false, you must manually commit.
>
> Having said that, I would expect shutdown to automatically rollback
> any open transactions at the time of shutdown.
>
> Brett
>
> Sent from my iPhone
>
> On Jun 9, 2010, at 10:32, oldmhe <mh...@yahoo.com> 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.
>>
>> Regarding your last question, my program does shutdown explicitly
>> (as shown
>> in my original post).
>>
>> 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 should release 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
>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/can%27t-delete-my-DB-directory-tp28782490p28825037.html
>> Sent from the Apache Derby Users mailing list archive at Nabble.com.
>>
>
>
--
View this message in context: http://old.nabble.com/can%27t-delete-my-DB-directory-tp28782490p28839396.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: can't delete my DB directory
Posted by Brett Wooldridge <br...@gmail.com>.
Even read operations create transactions (and locks). Because you set
autocommit to false, you must manually commit.
Having said that, I would expect shutdown to automatically rollback
any open transactions at the time of shutdown.
Brett
Sent from my iPhone
On Jun 9, 2010, at 10:32, oldmhe <mh...@yahoo.com> 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.
>
> Regarding your last question, my program does shutdown explicitly
> (as shown
> in my original post).
>
> 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 should release 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
>>
>>>
>>>
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/can%27t-delete-my-DB-directory-tp28782490p28825037.html
> Sent from the Apache Derby Users mailing list archive at Nabble.com.
>
Re: can't delete my DB directory
Posted by oldmhe <mh...@yahoo.com>.
Based on Brett Wooldridge's comments, a commit() is needed after read/query
operation. If so (and it does seem so), the only mystery is why a shutdown
doesn't release the resources. Since the files can be deleted after the
program exits, it seems likely that the embedded driver isn't closing them
as part of the shutdown logic -- which seems like a bug in the driver.
Below is a list of the remaining dirs/files (after the failed delete),
followed by the full list (with no delete):
Directory of .\UnloadFilesDB
06/11/2010 10:45 AM <DIR> .
06/11/2010 10:45 AM <DIR> ..
06/11/2010 10:44 AM <DIR> seg0
0 File(s) 0 bytes
Directory of .\UnloadFilesDB\seg0
06/11/2010 10:44 AM <DIR> .
06/11/2010 10:44 AM <DIR> ..
06/11/2010 10:44 AM 1,343,488 c400.dat
06/11/2010 10:44 AM 102,400 c411.dat
06/11/2010 10:44 AM 5,869,568 c440.dat
06/11/2010 10:44 AM 1,675,264 c451.dat
4 File(s) 8,990,720 bytes
Here is the full list (by removing the call to my removeDir() function):
Directory of .\UnloadFilesDB
06/11/2010 10:51 AM <DIR> .
06/11/2010 10:51 AM <DIR> ..
06/11/2010 10:51 AM <DIR> log
06/11/2010 10:50 AM <DIR> seg0
06/11/2010 10:50 AM 870 service.properties
1 File(s) 870 bytes
Directory of .\UnloadFilesDB\log
06/11/2010 10:51 AM <DIR> .
06/11/2010 10:51 AM <DIR> ..
06/11/2010 10:51 AM 48 log.ctrl
06/11/2010 10:51 AM 1,048,576 log11.dat
06/11/2010 10:51 AM 48 logmirror.ctrl
3 File(s) 1,048,672 bytes
Directory of .\UnloadFilesDB\seg0
06/11/2010 10:50 AM <DIR> .
06/11/2010 10:50 AM <DIR> ..
06/11/2010 10:50 AM 8,192 c10.dat
06/11/2010 10:50 AM 8,192 c101.dat
06/11/2010 10:50 AM 8,192 c111.dat
06/11/2010 10:50 AM 8,192 c121.dat
06/11/2010 10:50 AM 8,192 c130.dat
06/11/2010 10:50 AM 8,192 c141.dat
06/11/2010 10:50 AM 8,192 c150.dat
06/11/2010 10:50 AM 8,192 c161.dat
06/11/2010 10:50 AM 8,192 c171.dat
06/11/2010 10:50 AM 32,768 c180.dat
06/11/2010 10:50 AM 16,384 c191.dat
06/11/2010 10:50 AM 8,192 c1a1.dat
06/11/2010 10:50 AM 16,384 c1b1.dat
06/11/2010 10:50 AM 8,192 c1c0.dat
06/11/2010 10:50 AM 8,192 c1d1.dat
06/11/2010 10:50 AM 8,192 c1e0.dat
06/11/2010 10:50 AM 8,192 c1f1.dat
06/11/2010 10:50 AM 28,672 c20.dat
06/11/2010 10:50 AM 8,192 c200.dat
06/11/2010 10:50 AM 8,192 c211.dat
06/11/2010 10:50 AM 8,192 c221.dat
06/11/2010 10:50 AM 114,688 c230.dat
06/11/2010 10:50 AM 8,192 c241.dat
06/11/2010 10:50 AM 16,384 c251.dat
06/11/2010 10:50 AM 8,192 c260.dat
06/11/2010 10:50 AM 8,192 c271.dat
06/11/2010 10:50 AM 8,192 c281.dat
06/11/2010 10:50 AM 8,192 c290.dat
06/11/2010 10:50 AM 8,192 c2a1.dat
06/11/2010 10:50 AM 8,192 c2b1.dat
06/11/2010 10:50 AM 8,192 c2c1.dat
06/11/2010 10:50 AM 8,192 c2d0.dat
06/11/2010 10:50 AM 8,192 c2e1.dat
06/11/2010 10:50 AM 8,192 c2f0.dat
06/11/2010 10:50 AM 8,192 c300.dat
06/11/2010 10:50 AM 8,192 c31.dat
06/11/2010 10:50 AM 8,192 c311.dat
06/11/2010 10:50 AM 8,192 c321.dat
06/11/2010 10:50 AM 8,192 c331.dat
06/11/2010 10:50 AM 8,192 c340.dat
06/11/2010 10:50 AM 8,192 c351.dat
06/11/2010 10:50 AM 8,192 c361.dat
06/11/2010 10:50 AM 8,192 c371.dat
06/11/2010 10:50 AM 8,192 c380.dat
06/11/2010 10:50 AM 8,192 c391.dat
06/11/2010 10:50 AM 8,192 c3a1.dat
06/11/2010 10:50 AM 8,192 c3b1.dat
06/11/2010 10:50 AM 8,192 c3c0.dat
06/11/2010 10:50 AM 8,192 c3d1.dat
06/11/2010 10:50 AM 8,192 c3e1.dat
06/11/2010 10:50 AM 8,192 c3f1.dat
06/11/2010 10:50 AM 1,343,488 c400.dat
06/11/2010 10:50 AM 16,384 c41.dat
06/11/2010 10:50 AM 102,400 c411.dat
06/11/2010 10:50 AM 1,314,816 c420.dat
06/11/2010 10:50 AM 135,168 c431.dat
06/11/2010 10:51 AM 5,869,568 c440.dat
06/11/2010 10:51 AM 1,675,264 c451.dat
06/11/2010 10:50 AM 8,192 c51.dat
06/11/2010 10:50 AM 8,192 c60.dat
06/11/2010 10:50 AM 8,192 c71.dat
06/11/2010 10:50 AM 8,192 c81.dat
06/11/2010 10:50 AM 20,480 c90.dat
06/11/2010 10:50 AM 20,480 ca1.dat
06/11/2010 10:50 AM 8,192 cb1.dat
06/11/2010 10:50 AM 8,192 cc0.dat
06/11/2010 10:50 AM 8,192 cd1.dat
06/11/2010 10:50 AM 8,192 ce1.dat
06/11/2010 10:50 AM 8,192 cf0.dat
69 File(s) 11,165,696 bytes
Kristian Waagan-4 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
>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
--
View this message in context: http://old.nabble.com/can%27t-delete-my-DB-directory-tp28782490p28858414.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: can't delete my DB directory
Posted by Brett Wooldridge <br...@gmail.com>.
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 <Kr...@sun.com>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
>>>
>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
Re: can't delete my DB directory
Posted by Kristian Waagan <Kr...@Sun.COM>.
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
>>
>>>
>>>
>>
>>
>>
>
Re: can't delete my DB directory
Posted by oldmhe <mh...@yahoo.com>.
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.
Regarding your last question, my program does shutdown explicitly (as shown
in my original post).
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 should release 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
>
>>
>>
>
>
>
--
View this message in context: http://old.nabble.com/can%27t-delete-my-DB-directory-tp28782490p28825037.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: can't delete my DB directory
Posted by Kristian Waagan <Kr...@Sun.COM>.
On 04.06.10 18:51, oldmhe wrote:
> Prior to exiting, my Java program issues a shutdown, and then tries to delete
> the DB directory (recursively), but is not able to completely delete the
> directory. Here's the code:
>
> try {
> DriverManager.getConnection("jdbc:derby:;shutdown=true");
> } catch (SQLException eSQLException) {
> if (
> eSQLException.getErrorCode() == 50000
> &&
> "XJ015".equals(eSQLException.getSQLState())
> ) {
> // successful shutdown
> } else
> printSQLException(eSQLException);
> }
> removeDir(new File(dbnmString)); // remove DB directory
>
> (removeDir is my own function)
>
> If removeDir() is called before connecting to the DB, it works fine. But
> the above call to removeDir() only deletes some of the files and directories
> within dbnmString -- as if Derby is still accessing them (or has not closed
> them).
>
> I also tried dropping the DB just before the shutdown code, with the same
> results.
>
> Any ideas would be appreciated.
>
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
>
>