db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: [n00b] Recovering from program crashes
Date Tue, 03 Apr 2007 00:21:16 GMT
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


Mime
View raw message