![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
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? |
#3
| |||
| |||
|
|
On Jul 25, 12:05 am, rohithr... (AT) gmail (DOT) com 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 |
![]() |
| Thread Tools | |
| Display Modes | |
| |