We have a line of business application that is used for a small department. Like financial applications, this one is consistently about 4-6 years behind the current trends in application development. Version 9 which was just released a few months ago is finally web based. The version we're running, 8.something, is still based on the same model that Access databases are. I.e., file based databasing.
This particular application is excruciatingly sensitive to oplocks. We've fought this application for years as a result of that. Why is it so sensitive?
Any long time NetWare admin will tell you about PDOXUSRS.NET files. This particular application uses the same kind of access mode. One file is used to mediate who is authorized to access the application as a whole. While users are using the application they keep that file open, and update the file with their application level lock. Okay so far.
The problem comes with oplocks. How it is supposed to work:
One of the things that this vendor has done is decertify NetWare as a valid File Server to store this stuff. This is why I migrated the directory to a Windows 2003 server last night. And even there they had us do a reg-hack to turn off oplock support in Windows. They REALLY do not like oplocks.
Once this app goes web-based, it should help reduce the problems we have with that license file. I hope.
This particular application is excruciatingly sensitive to oplocks. We've fought this application for years as a result of that. Why is it so sensitive?
Any long time NetWare admin will tell you about PDOXUSRS.NET files. This particular application uses the same kind of access mode. One file is used to mediate who is authorized to access the application as a whole. While users are using the application they keep that file open, and update the file with their application level lock. Okay so far.
The problem comes with oplocks. How it is supposed to work:
- Station 100 opens LICENSE.LOG and requests an oplock on it
- Server, seeing no other stations with that file open, grants the oplock.
- Station 100 copies LICENSE.LOG to memory, thus improving access times to it.
- Station 105 opens LICENSE.LOG and requests and oplock on it.
- Server, seeing Station 100 has an oplock on it, tells Station 100 to release its oplock.
- Station 100 writes LICENSE.LOG to the server, and releases its oplock.
- Server tells Station 105 it can open the file, but can't have an oplock.
- Station 105 accesses the file without an oplock.
- Station 100 opens LICENSE.LOG and requests an oplock on it.
- Server, seeing no other stations with that file open, grants the oplock.
- Station 100 copies LICENSE.LOG to memory, thus improving access times to it.
- Station 100 crashes hard. Does not reset its connection to the server, and the Watchdog doesn't scavenge it.
- Station 105 opens LICENSE.LOG and requests an oplock on it.
- Server, seeing station 100 has an oplock on it, tells Station 100 to release its oplock.
- Station 100 is no longer there.
- Server waits until station 100 releases its oplock, which will be never.
- Station 105 doesn't get its lock. Application will not load for anyone else.
- Server Admin hard clears Station 100.
- Application Admin goes into LICENSE.LOG and cleans up bad entries.
- Application Admin tells all stations running Application to log out and log in again.
One of the things that this vendor has done is decertify NetWare as a valid File Server to store this stuff. This is why I migrated the directory to a Windows 2003 server last night. And even there they had us do a reg-hack to turn off oplock support in Windows. They REALLY do not like oplocks.
Once this app goes web-based, it should help reduce the problems we have with that license file. I hope.
Got to love it when a vendor de-certifies Netware because their application sucks. Oplocks is a pain, no matter what the operating system. Netware handles it as good as any.