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 Paul Taylor <pa...@fastmail.fm> on 2010/02/02 12:22:00 UTC

Best way to detect if embedded derby is being used by another application ?

Hi, I'm trying to prevent a program being run concurrently by trying to 
access the database but getting in a bit of a mess, what is the 
simplest/neated way of doing this.

thanks Paul

Re: Best way to detect if embedded derby is being used by another application ?

Posted by Bryan Pendleton <bp...@amberpoint.com>.
> 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



Re: Best way to detect if embedded derby is being used by another application ?

Posted by Paul Taylor <pa...@fastmail.fm>.
Dag H. Wanvik wrote:
> Paul Taylor <pa...@fastmail.fm> writes:
>
>   
>> Hi, I'm trying to prevent a program being run concurrently by trying
>> to access the database but getting in a bit of a mess, what is the
>> simplest/neated way of doing this.
>>     
>
> Normally (al least newer Derby releases), if you try to connect
> (implied boot) a Derby database which has already been booted by
> another VM you would get an error message. You could also check for
> the presence of the db.lck file in the database's directory before you
> attempt to boot a database.
>
>   /export/home/tmp/derby/sb/sb1/wombat:
>   :
>   -rw-r--r--   1 user group       38 feb.  2 15:30 db.lck   <------- 
>   -rw-r--r--   1 user group        4 feb.  2 15:30 dbex.lck
>   drwxr-xr-x   2 user group      512 feb.  2 15:30 log
>   drwxr-xr-x   2 user group     1536 feb.  2 15:30 seg0
>   -rw-r--r--   1 user group      860 feb.  2 15:30 service.properties
>   drwxr-xr-x   2 user group      512 feb.  2 15:30 tmp
>
> On a normal shutdown this file will be removed. An abnormal
> termination would leave the lock file in place, though, so that needs
> to be considered before you decide if that's a sufficient hint for
> your needs, since you could then risk starving the waiting VM..
>
> Dag
>
>   
 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., and this wast he crux 
of my problem , my code is 99% Java but there is 1% native code provided 
by a 3rd party that I have to call using Runtime that does crash 
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.

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.

Paul

Re: Best way to detect if embedded derby is being used by another application ?

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Paul Taylor <pa...@fastmail.fm> writes:

> Hi, I'm trying to prevent a program being run concurrently by trying
> to access the database but getting in a bit of a mess, what is the
> simplest/neated way of doing this.

Normally (al least newer Derby releases), if you try to connect
(implied boot) a Derby database which has already been booted by
another VM you would get an error message. You could also check for
the presence of the db.lck file in the database's directory before you
attempt to boot a database.

  /export/home/tmp/derby/sb/sb1/wombat:
  :
  -rw-r--r--   1 user group       38 feb.  2 15:30 db.lck   <------- 
  -rw-r--r--   1 user group        4 feb.  2 15:30 dbex.lck
  drwxr-xr-x   2 user group      512 feb.  2 15:30 log
  drwxr-xr-x   2 user group     1536 feb.  2 15:30 seg0
  -rw-r--r--   1 user group      860 feb.  2 15:30 service.properties
  drwxr-xr-x   2 user group      512 feb.  2 15:30 tmp

On a normal shutdown this file will be removed. An abnormal
termination would leave the lock file in place, though, so that needs
to be considered before you decide if that's a sufficient hint for
your needs, since you could then risk starving the waiting VM..

Dag