db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendle...@amberpoint.com>
Subject Re: Best way to detect if embedded derby is being used by another application ?
Date Wed, 03 Feb 2010 15:00:37 GMT
> I thought if there was an abnormal termination then the db.lck is left 
> in place and an attempt to boot the db will fail.

The first part is true, but the second should not be. It is OK for the db.lck
file to be left around after an abnormal termination. On the next boot,
the Derby recovery system will automatically recover the database, and,
upon completion, will allow the database to be booted back up.

> occasionally. But I've just tried starting my application , making 
> copies of db.lck and db.ex.lck and the starting the program again and it 
> actually starts okay.

This is in general not a safe practice, I think. You shouldn't need to
be directly manipulating the db.lck file yourself, and you shouldn't need
to be making copies of the db.lck file.

But if you:
- kill your application while it is running
- copy your database directory to a new location, copying *everything*
- start your application back up, booting the Derby database from that
   new location

Then you may in fact be successful; Derby will, as per above, automatically
recover the database and then allow it to be booted.

But you shouldn't need to do that. Just make sure the previous copy of
the program is gone, then start Derby back up and it will perform recovery.

> But in the real world I get users complaining that they cannot start the 
> program because it complains the program is already running, even though 
> it isnt, any ideas.

In every instance where I've ever seen this, the program *is* still running.

Sometimes Java programs get wedged into bad states where they no longer
respond to user input, but are still running as processes in the operating
system. You need to investigate how to use your operating system tools to view
the running processes on your system, and their list of open files (for
example, on Windows you can use the MSDN "sysinternals" tools to examine
your running Java processes and see what files they have open), and I am
confident that you will find that your users *do* still have a copy of the
program still running, perhaps in a fashion they didn't anticipate.



View raw message