More attempts to release the oci.dll lock

As a follow-up to the oci.dll locking issue and the use of unlocker that I explained

in an earlier blog post, when I conducted a session on "Patching with Grid Control",

a DBA suggested there was a Windows fix avaiable for the oci.dll locking issue.

I found Metalink Note 232827.1 which suggested that the svchost process

has the oci.dll locked on the machine. The note asked to shutdown Windows

services such as the Com+ Event System, MSDTC, and IIS. After

those services are shutdown the machine has to be rebooted in order for the

svchost process to release the oci.dll. The note suggested that these services

lock the oci.dll even though the user may not be using them.

I followed these steps, but it didnt make a difference. The ocii.dll

stayed locked even after the listeners were stopped.

The DBA then suggested to set the following registry key in Windows:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer]

AlwaysUnloadDLL=1

I already had this registry key set. so this was not the solution. I had to

reply on the previous unlocker strategy (see the previous blog post).

A further bit of reading suggested that Windows keeps dlls in memory on

purpose for a certain period of time even after the dll is not is use. This is

for performance reasons.

I do wonder why Unix has no such issues and the performance is still ok

in unix without such "hold things in memory for some indefinite time"

tactics. We never have such locking issues on unix.

A side note on this issue: when I removed and reloaded the registry key

"AlwaysUnloadDLL=1" into the registry, from then on whenever I tried to

start the Grid Control Management service, it failed to load. I remembered

reading somewhere on the internet that this registry key may be causing

a Java load issue, so I deleted the "AlwaysUnloadDLL=1" key straight

away, and the Grid Control management service started loading fine.

Whew!

Windows - you can love it, you can hate it.