John C. Turnbull wrote:
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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
