On Aug 4, 9:15 am, Don Anderson <don.ander...@[EMAIL PROTECTED]
> wrote:
> On Jul 25, 12:05 am, rohithr...@[EMAIL PROTECTED]
wrote:
>
> > 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.
>
> > 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.
|
