Discussion:
Release Locks on Application exit
(too old to reply)
r***@gmail.com
2007-07-25 04:05:23 UTC
Permalink
For getting lock am using the lock_vec method of DbEnv. If one
application locks certain objects and it exits without releasing the
locks, the Lock remains on those objects. The other application still
finds a lock on these objects.
Is there any option to release all the locks when the process exits?
Don Anderson
2007-08-04 00:15:17 UTC
Permalink
Post by r***@gmail.com
For getting lock am using the lock_vec method of DbEnv. If one
application locks certain objects and it exits without releasing the
locks, the Lock remains on those objects. The other application still
finds a lock on these objects.
This is true.
Post by r***@gmail.com
Is there any option to release all the locks when the process exits?
Not exactly, but you can achieve pretty much the same effect using
DB_ENV->failchk().
The idea is that each participating process and/or thread has a unique
id (this is usually
just the process id and thread id) and registers these ids using
DB_ENV->set_thread_id(). Then you may have a monitor process (or
the monitoring can in fact be distributed among several processes or
threads).
This monitor would call periodically call DB_ENV->failchk -- failchk
uses a previously
established 'isalive' callback to determine if any of the threads or
processes
have in fact died. If so, the locks associated with those threads or
processes
are released, and ongoing transactions associated with them are
aborted.

The monitoring doesn't have to be strictly polling behavior either.
If you have some way
to quickly detect a process or thread failure (possibly a parent
process calling
UNIX wait()), you can call failchk immediately and effectively release
the locks
immediately.

You must explicitly do a small bit of work to set this up, but it
should completely
solve the problem of failed processes or threads holding on to locks.

- Don Anderson
r***@gmail.com
2007-08-06 01:01:08 UTC
Permalink
Post by Don Anderson
Post by r***@gmail.com
For getting lock am using the lock_vec method of DbEnv. If one
application locks certain objects and it exits without releasing the
locks, the Lock remains on those objects. The other application still
finds a lock on these objects.
This is true.
Post by r***@gmail.com
Is there any option to release all the locks when the process exits?
Not exactly, but you can achieve pretty much the same effect using
DB_ENV->failchk().
The idea is that each participating process and/or thread has a unique
id (this is usually
just the process id and thread id) and registers these ids using
DB_ENV->set_thread_id(). Then you may have a monitor process (or
the monitoring can in fact be distributed among several processes or
threads).
This monitor would call periodically call DB_ENV->failchk -- failchk
uses a previously
established 'isalive' callback to determine if any of the threads or
processes
have in fact died. If so, the locks associated with those threads or
processes
are released, and ongoing transactions associated with them are
aborted.
The monitoring doesn't have to be strictly polling behavior either.
If you have some way
to quickly detect a process or thread failure (possibly a parent
process calling
UNIX wait()), you can call failchk immediately and effectively release
the locks
immediately.
You must explicitly do a small bit of work to set this up, but it
should completely
solve the problem of failed processes or threads holding on to locks.
- Don Anderson
Ya, I checked the failchk method. But am worried about the
performance.
In the isalive callback function I uses OpenProcess, OpenThread APIs
for checking the validity of PID and TID.
If the processes and threads using the locks and transactions are
increasing, i think the failchk method may be time consuming.

Also i feel that, when the thread is returned without releasing the
locks, the failchk has no affect on the locks done in that thread.
When i terminated the thread (used TerminateThread API) failchk is
releasing the locks done in that thread.

Loading...