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. thanks, bryan
