OPPORTUNISTIC LOCK AND WRITE-BEHIND CACHING

Summary

Running applications using EduAdmin databases on Windows networks can cause data corruption due to two Windows networking behaviours called opportunistic locking (on Windows servers) and write behind caching (on Windows clients).

Windows write behind caching is particularly flawed. It cannot handle high traffic to the same file and will corrupt files. An examination of Microsoft support papers lists their own applications as being vulnerable to file corruption. In the case of a flat file, for example, the once popular DBF file format, which is less susceptible to data corruption detection, you may have whole records that are garbage, but the database driver and the operator are unaware of this because that particular record is not being accessed. We have performed hundreds of file conversions of DBF files from competitor products that contain complete garbage, much to the dismay and bewilderment of the client when this is pointed out to them. To minimize the possibility of file corruption it is recommended that IT administrators pay particular attention to the rules and apply them rigorously.

The data files uses by EduAdmin are very sensitive to bad networks as they utilize sophisticated read and write techniques. There is nothing peculiar about this. Any decent software will always use decent file technology. Let us explain. If you insert a random character in a Word Document file, the chances are that it is trivial information and would not be noticed by either the word processor or the operator. This is because a word processor document is just one huge flat file. On the other hand, if you have a Zip file and introduce a random character, all sorts of bad things happen and data is permanently lost. Good data files are the same.

There is also the point, mostly overlooked by network administrators that, unlike a word processing file that it is written to once a day by one person at a time, database files are written to hundreds or thousands of times an hour by numerous users at the same time. So, if there is a problem with anything in the data stream, a data file will show it thousands of times faster than these flat files. Mostly, the problems are hardware related (bad NIC, bad cable, bad hub) but could also result from incorrect operating system settings.

The information in this paper is compiled from the latest information regarding these issues from Microsoft's documentation, our own in-house testing and customer reports.

Contents

• What is Opportunistic Locking?
• What is Write Behind Caching?
• What Operating Systems Are Affected?
• Disabling Write Behind Caching on Windows Workstations
• Disabling Opportunistic Locking on Windows Servers
• Disabling Opportunistic Locking on Windows Workstations
• Installing a New Redirector on Windows 95 Workstations
• Persistent Data Corruption
• Editing the Windows Registry
• Terms
• Additional Reading
• Disclaimer

What is Opportunistic Locking?

Opportunistic locking is a Windows-specific mechanism for client/server databases to allow multiple processes to lock the same file while allowing for local (client) data caching to improve performance over Windows networks.

Opportunistic locking assumes that the first application accessing a file (any file) has exclusive rights and locks out any other workstation attempting access. This means that, on a database with as little as two users, only one can access the database at a time because Windows does not know the difference between a document and a database.

Microsoft's documentation states "An opportunistic lock (also called an oplock) is a lock placed by a client on a file residing on a server. In most cases, a client requests an opportunistic lock so it can cache data locally, thus reducing network traffic and improving apparent response time. Opportunistic locks are used by network redirectors on clients with remote servers, as well as by client applications on local servers" and "Opportunistic locks are requests from the client to the server. From the point of view of the client, they are opportunistic. In other words, the server grants such locks whenever other factors make the locks possible.". You can read more about opportunistic locking in Microsoft's documentation. Please see the Additional Reading section for more information.

What is Write Behind Caching?

Write behind caching is local caching of write behind data on client (workstation) PCs. This type of caching is the default behavior of the Windows operating system and is intended to improve performance over Windows networks.

Problems with write behind caching usually occur if something unforeseen happens, such as a workstation crash, where data is not properly flushed from the workstation, which can lead to data corruption

Microsoft's documentation states that "Under extreme conditions, some multiuser database applications that use a common data store over a network connection on a file server may experience transactional integrity issues or corruption of the database files and/or indexes stored on the server. This typically applies to some so-called "ISAM style", or "record oriented" multiuser database applications, not to a client/server relational system like SQL Server." and "A hazard of local caching is that written data only has as much integrity as the client itself for as long as the data is cached on the client. In general, locally cached data should be flushed to the server as soon as possible." The truth of the matter is that the corruption occurs on SQL and even post-relational databases.

Write behind caching can be particularly troublesome. What does it attempt to do? The cache caches the write commands of your application and reports that it has been written. At that moment, the data is not sent to the server yet. While you continue with your application (immediately, no wait's for the write action), the write behind cache sends your data to the server in the application or computers idle time. Now picture a multi-user environment, where one user is updating a table while another is inserting a new record. Both need to write in this table, including it's header, and the application thinks it's already done. The cache does the write and puts back the header-info it had cached, on both workstations. This corrupts the file because its header information is outdated. Also when two workstations try to insert, the driver depends on the header information to know where there is a "free" record to write the data into. When the two workstations have the same header information, they will be overwriting each others record. Microsoft is aware of this which is why they devised Opportunistic File Locking. This means that, when one workstation requests an input output action for a file, Windows will lock that entire file, until it gets a signal from the workstation's cache that it has finished its action. This causes an unacceptable delay for the other users since they cannot access this file while it is locked (not even read). EduAdmin files can hold multiple tables but Windows has no way of knowing this and locks the entire file (all tables). EduAdmin, however, does know this and will only attempt to lock the table for the write action, leaving all other tables to be used by the other users and make the same table available as soon as the write has been completed. That's why you are better off letting EduAdmin handle the file-locking, instead of Windows. If you disable the Opportunistic Locking you also have to disable the write behind caching because you are disabling the safety mechanism for the cached writes and thereby causing file corruption.

You can read more about write behind caching in Microsoft's documentation. Please see the Additional Reading section for more information.

What Operating Systems are Affected?

All Windows operating systems in the NT family that act as database servers for EduAdmin data files (meaning that EduAdmin data files are stored there and accessed by other Windows PCs) need to have opportunistic locking disabled in order to minimize the chances of database corruption. This includes Windows NT, Windows 2000 and Windows XP.

All Windows operating systems in the 9X family that act as database clients for EduAdmin data files (meaning that they access EduAdmin data files stored on other Windows PCs) need to have write behind caching disabled in order to minimize the chances of database corruption. This includes Windows 95, Windows 98 and Windows ME.

Disabling Write Behind And Read Ahead Caching on Windows Workstations

All Windows operating systems in the 9X family that act as database clients for EduAdmin data files (meaning that they access EduAdmin data files stored on other Windows PCs) need to have write behind caching disabled in order to minimize the chances of database corruption. This includes Windows 95, Windows 98, Windows ME and the NT family.

The Windows registry entry that controls write behind caching on Windows network clients NT family is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

EnableOpLockForceClose REG_DWORD 0 or 1
Default: 0 (not disabled)

To disable oplocks, the value of EnableOpLockForceClose must be set to 1.

You can verify (or change or add, if necessary) this Registry value using the Windows Registry Editor (regedit.exe).
If you do change this Registry value, you will have to reboot the PC to ensure that the new setting goes into effect.

Please read the Microsoft disclaimer regarding editing of the Windows registry here.

STEPS:

1. Start > Run > Regedit.exe
2. Click on the + (plus sign) next to HKey_Local_Machine
3. Click on the + (plus sign) next to System
4. Click on the + (plus sign) next to CurrentControlSet
5. Click on the + (plus sign) next to Services
6. Click on the + (plus sign) next to LanManServer
7. Click on the Parameters entry on the left-hand side of Registry Editor

8. If the EnableOpLockForceClose registry value already exists (on the right-hand side of Registry Editor), ensure that its value is 1

9. If the EnableOpLockForceClose value already exists but its value is not 1, double-click on EnableOpLockForceClose to change its value to 1

10. If the EnableOpLockForceClose entry does not exist, right-click in the white space of the right-hand side of Registry Editor
11. Select New > DWORD value
12. Rename the value to EnableOpLockForceClose 
13. Double-click on EnableOpLockForceClose to change its value to 1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

EnableOplocks REG_DWORD 0 or 1
Default: 1 (true)

To disable oplocks, the value of EnableOplocks must be set to 0.

You can verify (or change or add, if necessary) this Registry value using the Windows Registry Editor (regedit.exe).
If you do change this Registry value, you will have to reboot the PC to ensure that the new setting goes into effect.

Please read the Microsoft disclaimer regarding editing of the Windows registry here.

STEPS:

1. Start > Run > Regedit.exe
2. Click on the + (plus sign) next to HKey_Local_Machine
3. Click on the + (plus sign) next to System
4. Click on the + (plus sign) next to CurrentControlSet
5. Click on the + (plus sign) next to Services
6. Click on the + (plus sign) next to LanManServer
7. Click on the Parameters entry on the left-hand side of Registry Editor

8. If the EnableOplocks registry value already exists (on the right-hand side of Registry Editor), ensure that its value is 0

9. If the EnableOplocks value already exists but its value is not 0, double-click on EnableOplocks to change its value to 0

10. If the EnableOplocks entry does not exist, right-click in the white space of the right-hand side of Registry Editor
11. Select New > DWORD value
12. Rename the value to EnableOplocks 
13. Double-click on EnableOplocks to change its value to 0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

EnableOpLockForceClose REG_DWORD 0 or 1
Default: 0 (not disabled)

To disable oplocks, the value of EnableOpLockForceClose must be set to 1.

You can verify (or change or add, if necessary) this Registry value using the Windows Registry Editor (regedit.exe).
If you do change this Registry value, you will have to reboot the PC to ensure that the new setting goes into effect.

Please read the Microsoft disclaimer regarding editing of the Windows registry here.

STEPS:

1. Start > Run > Regedit.exe
2. Click on the + (plus sign) next to HKey_Local_Machine
3. Click on the + (plus sign) next to System
4. Click on the + (plus sign) next to CurrentControlSet
5. Click on the + (plus sign) next to Services
6. Click on the + (plus sign) next to LanManWorkstation
7. Click on the Parameters entry on the left-hand side of Registry Editor

8. If the EnableOpLockForceClose registry value already exists (on the right-hand side of Registry Editor), ensure that its value is 1

9. If the EnableOpLockForceClose value already exists but its value is not 1, double-click on EnableOpLockForceClose to change its value to 1

10. If the EnableOpLockForceClose entry does not exist, right-click in the white space of the right-hand side of Registry Editor
11. Select New > DWORD value
12. Rename the value to EnableOpLockForceClose 
13. Double-click on EnableOpLockForceClose to change its value to 1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManWorkstation\Parameters

EnableOplocks REG_DWORD 0 or 1
Default: 1 (true)

To disable oplocks, the value of EnableOplocks must be set to 0.

You can verify (or change or add, if necessary) this Registry value using the Windows Registry Editor (regedit.exe).
If you do change this Registry value, you will have to reboot the PC to ensure that the new setting goes into effect.

Please read the Microsoft disclaimer regarding editing of the Windows registry here.

STEPS:

1. Start > Run > Regedit.exe
2. Click on the + (plus sign) next to HKey_Local_Machine
3. Click on the + (plus sign) next to System
4. Click on the + (plus sign) next to CurrentControlSet
5. Click on the + (plus sign) next to Services
6. Click on the + (plus sign) next to LanManWorkstation
7. Click on the Parameters entry on the left-hand side of Registry Editor

8. If the EnableOplocks registry value already exists (on the right-hand side of Registry Editor), ensure that its value is 0

9. If the EnableOplocks value already exists but its value is not 0, double-click on EnableOplocks to change its value to 0

10. If the EnableOplocks entry does not exist, right-click in the white space of the right-hand side of Registry Editor
11. Select New > DWORD value
12. Rename the value to EnableOplocks 
13. Double-click on EnableOplocks to change its value to 0

On versions of Windows 95 prior to the OSR2 release, in addition to disabling write behind and read ahead caching by making the appropriate Windows registry settings, you may have to install a new redirector (vredir.vxd) as well. The OSR2 version of Windows 95, comes pre-installed with the newer redirector. Do not install this redirector on versions of Windows 95 other than versions prior to OSR2 or other Windows operating systems.

Microsoft has provided a new vredir.vxd for Windows 95 (version 4.00.955) that does disable the buffering of shared files on Windows networks. If you have a version of the redirector prior to 4.00.955, you should install the new redirector. The redirector executable is a self-installing program provided by Microsoft. Run it under Windows 95 and it installs itself and makes the needed changes to your Windows registry. You then need to restart Windows 95 for the changes to take effect.

You can download the updated redirector from ftp://ftp.eduadmin.com/download/misc/vrdr2upd.exe.

This new redirector removes the local caching that the old redirector included. The local caching would cause data errors when retrieving data from a Windows server. The new redirector has been extensively tested by EduAdmin and does indeed solve the problems with data reliability between a Windows 95 workstation and a Windows server. This redirector is not needed if accessing data on a Novell NetWare server. However, installing the new redirector will have no detrimental effects on sites not using Windows servers. Thus, our general recommendation would be to use the new redirector at all customer sites.

Note: When you search the Windows registry for vredir.vxd on a Windows 95 machine that has not had either the patch or the OSR2 revision installed, the first entry found is simply the component name and its associated data (displayed in hex). On any machine which was shipped with the OSR2 release, or had the patch installed, the first entry that is found displays a comment about "Samba UNIX" and the revision number 4.00.955 beneath the comment (the screen with the hex data will be the second one found).

• Section of the Microsoft MSDN Library on opportunistic locking: 
  Opportunistic Locks, Microsoft Developer Network (MSDN), Windows Development > Windows Base Services > Files and I/O > SDK Documentation > File Storage > File Systems > About File Systems > Opportunistic Locks, Microsoft Corporation.
  URL=http://msdn.microsoft.com/library/en-us/fileio/storage_5yk3.asp

• Microsoft Knowledge Base Article Q224992 "Maintaining Transactional Integrity with OPLOCKS", Microsoft Corporation, April 1999, URL=http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224992

• Microsoft Knowledge Base Article Q296264 "Configuring Opportunistic Locking in Windows 2000", Microsoft Corporation, April 2001, URL=http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296264

• Microsoft Knowledge Base Article Q129202 "PC Ext: Explanation of Opportunistic Locking on Windows NT", Microsoft Corporation, April 1995, URL=http://support.microsoft.com/default.aspx?scid=kb;en-us;Q129202

• Visit the EduAdmin Worldwide Home page for information about all of our support offerings. http://www.eduadmin.com.