Spurious Lock Conflicts in Advanced Revelation

When attempting to lock a record in a linear hash file, it is possible to receive notification that the record is already locked or is in use, when in fact the record has not been explicitly locked and is not currently being used. This may be because the system generated identical lock values for two records with similar keys. This technical bulletin explains why these lock conflicts occur and how they can be avoided.

To set a record lock on a record in a linear hash file, Advanced Revelation uses a hashing algorithm to generate a lock value. The hashing algorithm uses the record key and part of the data file's DOS filename, as illustrated in the following example.

DOS filename = C:\AREV\DATA\REV12345.LK
Record key = RECORD.KEY.ONE
Hash string = 12345.LRECORD.KEY.ONE

12345.LRECORD.KEY.ONE
       ||
       \/
[hashing algorithm]
       ||
       \/
   LOCK VALUE

Note that the hash string includes only the numeric part, the period, and the first letter of the extension of the DOS filename are included in the hash string.

If the hash string is longer than 28 characters, the hashing algorithm uses only the last 28 characters to generate a lock value. Combinations of DOS filenames and record keys may form hash strings that are identical in their entirety or in their last 28 characters. If the last 28 characters of the hash strings are identical, the lock values will also be identical.

Because all record keys in a single data file are unique, it is unlikely that there will be conflicts between keys that are less than 28 characters in length. However, to avoid spurious lock conflicts between record keys 28 characters or more in length, keys should be unique in the last 28 characters.

The restrictions are somewhat greater when dealing with more than one data file, because keys in separate files may be identical in their entirety. Record keys in two different data files that are identical and either 26 or 27 characters long will result in a hashing string whose last 28 characters are identical. This is because all primary data files use ".LK" as the DOS filename extension. It is possible to have conflicts with keys even shorter than 26 characters if the last character(s) of the numeric part of the two DOS filenames happen to be the same.

Network locking mechanisms use the lock value generated by the hashing algorithm to set a lock at a network server. The hashing algorithm was designed with two purposes in mind:

• Maximize the number of unique lock values that can be generated.
• Generate lock values that are compatible with all the types of networks supported by Advanced Revelation.

The length of the string to be hashed is limited, because networks that only support byte-range locks restrict the lock value to a 32-bit number. This limitation makes it impossible to generate a unique value for every possible file and record key combination.

On Novell networks the lock value is converted to a logical record name and is used to set a logical record lock on the server where the record is stored. All locks are set in a logical record lock table that is shared by all users of a server. Therefore, users of different copies of Advanced Revelation can share data files on these networks.

On other networks, the lock value is converted to a byte-range lock offset value and used to set a byte-range lock on a Revelation system file. Revelation G2B sets all locks on the REV.EXE file. Advanced Revelation versions 1.15 and lower set all locks on the AREV.EXE file. Advanced Revelation versions 1.16 and higher set all locks on the file REVBOOT.

On networks that use byte-range locking, all locks are set on one file that is used exclusively by a particular copy of Advanced Revelation. As a result, all Advanced Revelation users who want to share data files on these networks must execute the same copy of Advanced Revelation.

The most frequent source of spurious lock conflicts occurs when Advanced Revelation linear hash volumes are duplicated using the DOS COPY command. Using DOS to copy linear hash volumes produces files that have identical DOS filenames and contain identical record keys. To avoid lock conflicts, copy linear hash files using the Advanced Revelation FILECOPY command, which generates unique DOS filenames for new files.

Note: On Novell networks, you can use the COPY command if the files are copied to a different server. This is because the locks go only to the server hosting the data.

Using the information presented in this technical bulletin and adhering to the suggested guidelines for creating record keys will prevent the occurrence of spurious record lock conflicts. If the guidelines are not followed rigorously, spurious lock conflicts may occur, but as the information presented in this technical bulletin demonstrates, these conflicts are not necessarily an indication of abnormal system behavior or data corruption.