How to delete lock files after cell is closed?

First of all, DD_DONT_DO_OS_LOCKS does not prevent lock files from being created (and you really wouldn't want it to do that; I've seen customers who routinely delete the lock files and then they complain because they lose data; the system then has no idea that somebody else has something open for edit).

That environment variable is to control whether it uses the operating system lock mechanism to lock the lock file whilst it is being created - this is a second level of locking to help prevent issues where two processes both try to lock it at the same time.

Lock files should get removed once either the file/cellView is no longer in edit mode, or has been closed. Also, if virtuoso exits (normally), they should get removed. In general the only case where lock files remain is when virtuoso has exited abnormally (killed or crashed).

When that happens, there is a mechanism to recover stranded locks when you next try to open the same file/cellView for edit. What happens is that it consults the lock file, and checks to see what machine had the lock - and also what the process id and so on is. It then tries to ask a process called clsbd which is running on each machine where Virtuoso has been started at some point, whether that process is still running. If it is, then the request to reclaim the lock is denied; if it isn't, the lock may be reclaimed and then the lock file is removed and a new one created for the new locking process. If however it either cannot contact clsbd on the remote machine (maybe it is not running, or maybe the machine is not up, or maybe there's a firewall in the way blocking the ports used), it errs on the side of caution and denies the lock recovery. However, it allows a certain amount of time before it gives up - because maybe you have a network glitch and the time taken to respond is too long.

We do provide a utility, clsAdminTool to aid with finding and removing lock files, but you should always use this with caution because this doesn't do the checking that the remote process is still running or not.

If you are finding a case where the lock files are not being removed, first check that it really has closed it - look in File->Close Data in the CIW - maybe there is more than one reference to the cellView in memory and hence it has kept it in memory - this can easily happen particularly if you have SKILL code which opens cellViews but doesn't match the opens with corresponding closes (it keeps a count of opens versus closes and only when they match does it purge from memory and release the lock. However, close data would fix that, as would exiting virtuoso).

Hope this helps!

Regards,

Andrew.

Provided that the machine which had the crash has since had virtuoso run on it again (or the "clsbd" deamon is started directly), it shouldn't be necessary to use clsAdminTool. Running virtuoso would cause clsbd to start, and then if virtuoso on another machine (or the same machine) finds the file is locked, it can consult with the clsbd on the machine with the lock to see if the process that was locking the file is still running or not. If it's not still running, the lock can safely be reclaimed.

clsAdminTool (in general) should only be needed when there is a lock and the machine is no longer accessible (i.e. if it's still powered down) - or if clsbd can't be started for some reason (not sure why).

Andrew.