Dag H. Wanvik wrote:
Paul Taylor <[email protected]> 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
