Par2: Opportunistic locking in NT 1999-11-18 -- Matt Fozard Here's an article I found a while back when investigating corruption in my
Clarion files. I think it's what you're looking for. Note the part at the end
about Win95 clients too...
Regards,
Matt Fozard
First Option Ltd.
RFCB (File Handles Caching) and Opportunistic Locking
Microsoft introduced an operating system feature in Windows NT that caches
file handles called RFCB Caching. This was done in order to increase the
file handling performance of specific kinds of Windows based applications on
an NT server (such as client/server based applications).
This feature can cause problems in traditional DOS based database programs
that use Standard File and Record Locking (using SHARE.EXE or SHARE.386),
such as Solution System 2 or CaseBASE. This problem has also been reported
in programs written in dBASE, Clipper and Microsoft's own Access and Foxpro.
The technical explanation of this is as follows: the NT Server service
caches file handles (RFCBs) associated with files it has opened on behalf of
a client (workstation) request. Although write requests proceed normally,
close requests are acknowledged by the server, but are buffered from the
file system. This is intended to optimize response time to repeated
open/close operations performed by clients (which Solution System 2 and
CaseBASE do a great deal of). Additionally, Opportunistic Locking (oplock)
is an optimization that is a logical extension of the way a client caches
its own file close request and relies on the server to arbitrate future
requests for file access by other clients, rather than allowing the
application to actually close it's own file handles. In many situations,
Oplocks must also be disabled for compatibility purposes. Because of
Opportunistic Locking's relationship with file closes, RFCB Caching and
Opportunistic Locking go hand-in-hand.
Microsoft presumes you will not be running traditional DOS database
applications on your new server and as a result, both of these potentially
data corrupting features are activated by default upon installation of
Windows NT Server.
An obvious sign that a file is being held open is the reported file size may
be zero. In Control Panel, the Server option displays open files, when in
fact, they are only open by the Server service in a cached mode. Other signs
may include sharing violations or data and index file corruption, or at
least an apparent lack of synchronization between the data at various
workstations. Solution System 2 and CaseBASE rely on the file handles
actually being closed. Local file operations are not serviced by the server
and are not subject to RFCB Caching.
To disengage both opportunistic locking and RFCB Caching, make the following
modifications using the Registry editor (REGEDT32.EXE in Windows NT Server
3.51, and REGEDIT.EXE in Windows NT Server 4.0). Note that only your
qualified service representative should do this.
Verify (and correct, if necessary) these NT Server parameters:
EnableOpLockForceClose REG_DWORD set to 1 (default=0)
EnableOplocks REG_DWORD set to 0 (default=1)
CachedOpenLimit REG_DWORD set to 1 (default=0)
----------------------------------------------------------------------------
----
Step 1
Choose: HKey_Local_Machine ->
System ->
Current Control Set ->
Services ->
LanmanServer ->
Parameters ->
If the value EnableOpLockForceClose exists
Double-click on it, or select it, then pull down "Edit"
and choose DWORD ->
In DWORD Editor, Hex selected, enter the value 1
Or, if the value EnableOpLockForceClose does NOT exist
Pull down "Edit" and choose Add value ->
Value name: EnableOpLockForceClose ->
Data type : REG_DWORD ->
Press OK ->
In DWORD Editor, Hex selected, enter the value 1
----------------------------------------------------------------------------
----
Step 2
Choose: HKey_Local_Machine ->
System ->
Current Control Set ->
Services ->
LanmanServer ->
Parameters ->
If the Value EnableOpLocks exists
Double-click on it, or select it, then pull down "Edit"
and choose DWORD ->
In DWORD Editor, Hex selected, enter the value 0
Or if the value EnableOpLocks does NOT exist
Pull down "Edit" and choose Add value ->
Value name: EnableOpLocks ->
Data type : REG_DWORD ->
Press OK ->
In DWORD Editor, Hex selected, enter the value 0
----------------------------------------------------------------------------
----
Step 3
Choose: HKey_Local_Machine ->
System ->
Current Control Set ->
Services ->
LanmanServer ->
Parameters ->
If the value CachedOpenLimit exists
Double-click on it, or select it, then pull down "Edit"
and choose DWORD ->
In DWORD Editor, Hex selected, enter the value 1
Or, if the value CachedOpenLimit does NOT exist
Pull down "Edit" and choose Add value ->
Value name: CachedOpenLimit ->
Data type : REG_DWORD ->
Press OK ->
In DWORD Editor, Hex selected, enter the value 1
----------------------------------------------------------------------------
----
After these changes have been made, shut down your server and start it back
up. These changes will not take effect until you do this!
When running Windows NT Server, it is very important that you ensure that
you have applied all the current service packs from Microsoft. Microsoft
maintains a free download site at
http://www.microsoft.com/msdownload/default.htm.
If you are not familiar with doing this, contact your hardware and software
vendor to do it for you.
A Note About Windows95
It is important to note that the updated VREDIR.VXD workstation fix is also
required for stable operations when using Windows 95 workstations. There are
actually two different operating-system-level functions at work when using
combinations of Windows 95 and Windows NT workstations and Windows NT
server: local buffering of data at the Windows 95 workstations (controlled
by VREDIR.VXD and its registry settings at the workstation) and
opportunistic-locking buffering at the Windows NT workstations (controlled
by combinations of settings at the workstation and server, but only
supported by disabling it at the server).
Printed May 7, 2024, 10:55 am This article has been viewed/printed 35124 times. |