Re: 'drop tablespace' produces a file/table lock??

Brian Peasland <dba_at_remove_spam.peasland.com> wrote

> I've also seen it with DLL files and Oracle Forms and Reports. When
> running a Forms application, accessing centrally located Forms and
> Reports DLL files, a lock was placed on the file. In some extreme cases,
> we've had to reboot the end user's workstations. Big pain in the....when
> dealing with Windows and its file locking.

You will find the exact same to be true when dealing with DSOs on Unix. This is how it IS SUPPOSE TO WORK. Period. Don't blame the operating system for your lack of understanding on how DLL locking works.

To explain briefly.

A DLL is shared piece of code. The CS (code segment) gets loaded once. The sharable part. The DLL uses the DS (data segment) of the calling EXE. The kernel keeps track of DLLs via an usage (aka reference) count. Everytime a LoadLib() or implictic load is done of a DLL, its usage count is incremented. BTW, this count applies to modules too. When the count reaches zero, the DLL is unloaded from memory.

Only at that time, the DLL files becomes unlocked.

Thus, while the DLL file can not be deleted, it means that Windows still have it loaded. A DLL can remain loaded despite the program (EXE) terminating - for example, the program has a bug/feature that causes LoadLib() to be called more than once for the same DLL. But it somehows forgot to call FreeLib() for each of those LoadLib() handles. Or the program exits/terminates/crashes dirty.. never calling the FreeLib() via an exception handler. Same thing. DLL's usage count is not decremented and Windows still consider that DLL to be in use.

When developing (and having developers like you seem to have to that writes crap code), you can write a cleanup app that unloads your crashed app's DLLs from memory. From the Windows Help files : "LoadLibrary maps the module into the address space of the calling process, if necessary, and increments the module's reference count, if it is already mapped. GetModuleHandle, however, returns the handle of a mapped module without incrementing its reference count."

Which means that you do a while GetModuleHandle() is not null, FreeLib(). And yes - it does work and have been since the Win16 API and Windows 3.1.

--
Billy