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 "John C. Turnbull" <oz...@ozemail.com.au> on 2007/04/02 02:07:37 UTC
[n00b] Recovering from program crashes
I have just started to use Derby for configuration data for an application
and have found that whenever the app terminates unexpectedly then Derby will
not start the next time I start the application as it complains that it's
already been opened. At the moment, I need to reboot my machine to clear
whatever flag/data is indicating that the database is still open.
Is there a cleaner way to close the database? Ideally my app would try to
start Derby and if it gets the error about it already being open then it
would somehow clean up and close the database (that is if the application is
not actually running in another instance already) and then open it properly.
And loving it,
John C. Turnbull
_________________________________________________
"The old lighter-in-the-gun-in-the-rabbit trick!"
-Maxwell Smart
RE: [n00b] Recovering from program crashes
Posted by "John C. Turnbull" <x2...@set.net.au>.
Hi Oystein,
Thanks for the reply. Comments inline.
> -----Original Message-----
> From: Oystein.Grovlen@Sun.COM [mailto:Oystein.Grovlen@Sun.COM]
> Sent: Monday, 2 April 2007 18:13
> To: Derby Discussion
> Subject: Re: [n00b] Recovering from program crashes
>
> Normally the lock file used to lock the database for concurrent access
> by other applications, should be cleaned up automatically, but I seem
> to
> recall that there have earlier been some discussions about platform
> differences in this area.
>
> What error do you get, exactly?
[JCT]
SQL Exception: Failed to start database 'JohnDB', see the next exception for
details.
SQL Exception: Another instance of Derby may have already booted the
database D:\Projects\JohnDB.
> Which platform (OS and JVM version) are you running on?
[JCT]
OS: Windows Vista Ultimate x64
JVM: Java 6.0 Update 1 (b03)
I was also getting exactly the same error when running with this JVM under
Windows XP Professional 32-bit.
Any ideas?
Thanks,
John
RE: [n00b] Recovering from program crashes
Posted by "John C. Turnbull" <oz...@ozemail.com.au>.
Hi Mike,
> Can you describe what it means that your program "crashed"? Did the
> JVM
> that was running it go down? Are you using network server, if so is it
> possible your client program crashed but left the network server up and
> still connected to database?
[JCT]
The program crashes when it encounters a fatal exception such as a NPE. I
agree that the JVM should exit at this point too but it must be living on
for some reason. I will have to investigate this further. BTW, I am not
using the network server.
Thanks,
John
Re: [n00b] Recovering from program crashes
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Stanley Bradbury wrote:
> Hi John -
> When using a version 1.4.2 JVM or higher and the default Derby property
> set you should not need to manually remove the db.lck file.
Just to reiterate if your JVM is higher that 1.4.2 then none of the
below applies. Unless there is a bug, Derby will only lock you out if
an existing JVM still has a lock on that file. There should be no
OS/JVM/machine variations if you have version 1.4.2 or higher and are
seeing this message.
Can you describe what it means that your program "crashed"? Did the JVM
that was running it go down? Are you using network server, if so is it
possible your client program crashed but left the network server up and
still connected to database?
The message
> you are getting indicates that the db.lck file exists AND a process has
> the file locked. Generally when an embedded Derby application aborts
> the JVM aborts too thus releasing the filelock. The next time database
> access is attempted the db.lck is found but it is not locked so Derby
> removes the old file, creates a new one and boots the database. The
> property derby.database.forceDatabaseLock changes this behavior so unset
> this if it is set:
> [On some platforms, if set to true, prevents Derby from booting a
> database if a db.lck file is present in the database directory].
> Otherwise check to see if, after the application crashes, there is still
> a JVM process running. If so need to either reattach to that process or
> kill the JVM process to get past the filelock or release it.
>
> HTH
>
>
>
Re: [n00b] Recovering from program crashes
Posted by Stanley Bradbury <St...@gmail.com>.
John C. Turnbull wrote:
>> -----Original Message-----
>> From: Oystein.Grovlen@Sun.COM [mailto:Oystein.Grovlen@Sun.COM]
>> Sent: Tuesday, 3 April 2007 02:44
>> To: Derby Discussion
>> Subject: Re: [n00b] Recovering from program crashes
>>
>> There is a file in the db directory db.lck that is created to prevent
>> dual booting. See
>> http://db.apache.org/derby/docs/10.2/devguide/cdevdvlp20458.html for
>> more info.
>>
>> By removing that file you should be able to boot. However, make sure
>> that no other process is accessing the database. Derby will try to
>> delete this file itself. If it fails, it is an indication that some
>> other process has an open file descriptor for this file.
>>
>
> [JCT]
> When does Derby try to delete the lock file? When it shuts down or when it
> starts up? If the program crashes then obviously Derby won't get a chance
> to delete the lock file.
>
>
>> Could it be
>> that a process that earlier has accessed the DB is hanging and not
>> actually removed until you reboot the DB?
>>
>
> [JCT]
> No, this is not what's happening. It seems that if the program that access
> the Derby database crashes then it won't be able to start the database the
> next time it starts. Maybe it is just as simple as deleting the lock file
> when this happens (but only after establishing for sure that a second
> instance of the application is not already running).
>
> Thanks,
>
> John
>
>
Hi John -
When using a version 1.4.2 JVM or higher and the default Derby property
set you should not need to manually remove the db.lck file. The message
you are getting indicates that the db.lck file exists AND a process has
the file locked. Generally when an embedded Derby application aborts
the JVM aborts too thus releasing the filelock. The next time database
access is attempted the db.lck is found but it is not locked so Derby
removes the old file, creates a new one and boots the database. The
property derby.database.forceDatabaseLock changes this behavior so unset
this if it is set:
[On some platforms, if set to true, prevents Derby from booting a
database if a db.lck file is present in the database directory].
Otherwise check to see if, after the application crashes, there is still
a JVM process running. If so need to either reattach to that process or
kill the JVM process to get past the filelock or release it.
HTH
RE: [n00b] Recovering from program crashes
Posted by "John C. Turnbull" <oz...@ozemail.com.au>.
> -----Original Message-----
> From: Oystein.Grovlen@Sun.COM [mailto:Oystein.Grovlen@Sun.COM]
> Sent: Tuesday, 3 April 2007 02:44
> To: Derby Discussion
> Subject: Re: [n00b] Recovering from program crashes
>
> There is a file in the db directory db.lck that is created to prevent
> dual booting. See
> http://db.apache.org/derby/docs/10.2/devguide/cdevdvlp20458.html for
> more info.
>
> By removing that file you should be able to boot. However, make sure
> that no other process is accessing the database. Derby will try to
> delete this file itself. If it fails, it is an indication that some
> other process has an open file descriptor for this file.
[JCT]
When does Derby try to delete the lock file? When it shuts down or when it
starts up? If the program crashes then obviously Derby won't get a chance
to delete the lock file.
> Could it be
> that a process that earlier has accessed the DB is hanging and not
> actually removed until you reboot the DB?
[JCT]
No, this is not what's happening. It seems that if the program that access
the Derby database crashes then it won't be able to start the database the
next time it starts. Maybe it is just as simple as deleting the lock file
when this happens (but only after establishing for sure that a second
instance of the application is not already running).
Thanks,
John
Re: [n00b] Recovering from program crashes
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
There is a file in the db directory db.lck that is created to prevent
dual booting. See
http://db.apache.org/derby/docs/10.2/devguide/cdevdvlp20458.html for
more info.
By removing that file you should be able to boot. However, make sure
that no other process is accessing the database. Derby will try to
delete this file itself. If it fails, it is an indication that some
other process has an open file descriptor for this file. Could it be
that a process that earlier has accessed the DB is hanging and not
actually removed until you reboot the DB?
--
Øystein
RE: [n00b] Recovering from program crashes
Posted by "John C. Turnbull" <oz...@ozemail.com.au>.
Hi Oystein,
Thanks for the reply. Comments inline.
> -----Original Message-----
> From: Oystein.Grovlen@Sun.COM [mailto:Oystein.Grovlen@Sun.COM]
> Sent: Monday, 2 April 2007 18:13
> To: Derby Discussion
> Subject: Re: [n00b] Recovering from program crashes
>
> Normally the lock file used to lock the database for concurrent access
> by other applications, should be cleaned up automatically, but I seem
> to recall that there have earlier been some discussions about platform
> differences in this area.
>
> What error do you get, exactly?
[JCT]
SQL Exception: Failed to start database 'JohnDB', see the next exception for
details.
SQL Exception: Another instance of Derby may have already booted the
database D:\Projects\JohnDB.
> Which platform (OS and JVM version) are you running on?
[JCT]
OS: Windows Vista Ultimate x64
JVM: Java 6.0 Update 1 (b03)
I was also getting exactly the same error when running with this JVM under
Windows XP Professional 32-bit.
Any ideas?
Thanks,
John
Re: [n00b] Recovering from program crashes
Posted by Øystein Grøvlen <Oy...@Sun.COM>.
John C. Turnbull wrote:
> I have just started to use Derby for configuration data for an
> application and have found that whenever the app terminates unexpectedly
> then Derby will not start the next time I start the application as it
> complains that it’s already been opened. At the moment, I need to
> reboot my machine to clear whatever flag/data is indicating that the
> database is still open.
>
>
>
> Is there a cleaner way to close the database? Ideally my app would try
> to start Derby and if it gets the error about it already being open
> then it would somehow clean up and close the database (that is if the
> application is not actually running in another instance already) and
> then open it properly.
>
Normally the lock file used to lock the database for concurrent access
by other applications, should be cleaned up automatically, but I seem to
recall that there have earlier been some discussions about platform
differences in this area.
What error do you get, exactly?
Which platform (OS and JVM version) are you running on?
--
Øystein