Re: Kernel locks or file locks?

Robert Brass (bbrass@world.std.com) wrote: : Hi, : Sometimes a table gets locked up. We called informix and they said : we needed to reboot the system to free up the locks, because we : had kernel level locking. They said it was operating system dependant that : determins whether we have file locks that can be easily removed or : kernel locks which can only be removed by a reboot. I have never heard : of such a thing. Is this true? Can I somehow switch to file level locking? : Do I need to check with SUN? If it is true, is there anyway to get the : locks released without rebooting? The locks are maintained by the kernel but held by processes. If a lock is not released it should be sufficient to somehow terminate the guilty process (but without using kill -9, if possible). If locks are still held with no DB processes running then you have problems with the OS. An OS upgrade might be an appropriate remedy. BTW zombie processes can never hold locks. It is possible for a process to become stuck in kernel mode, so that it cannot be killed, but this is usually caused a kernel bug. It is unfortunately difficult to tell what locks are held and by which processes at any time. I don't know whether Sun provides a tool to help with this. All this information can in theory be gathered by probing kernel memory. File-based locking works poorly at best, and should be avoided. That's why Informix doesn't use it when kernel-based locking is available. Informix OnLine uses another locking scheme based on shared memory. It is efficient and yet does not rely directly on the kernel, so it tends to be more consistently implemented across different platforms. It also does not require a reboot--bringing OnLine off-line is enough to clear any locks held. (That can be just as traumatic as a reboot, however, unless you have multiple OnLine instances running. Then only the affected instance need be stopped.) There are other reasons to use OnLine in favor of SE; you may want to consider it. -Jeff