Record Locking

For Record Locking Business Rules! uses a "Virtual Record" to lock individual records. Instead of locking the actual bytes of a record, it locks a single byte in an area that is unused by the file.

BR 3.8 & Prior used 31 bit record locking. This provided for 2**31 or 2,147,483,648 maximum bytes in a data file. BR 3.9 used 30 bit record locking. This provided for 2**30 or 1,073,741,824 maximum bytes in a data file.

In both cases, BR used a "Virtual Byte" Starting at around 1 gigabyte.

Instead of locking record 1, record 1,000,000,001 was locked.
Instead of locking record 2, record 1,000,000,002 was locked.
Instead of locking record 3, record 1,000,000,003 was locked.
Instead of locking record 4, record 1,000,000,004 was locked.

This allowed for 73,741,824 records to be locked when using 30 bit record locking.

The problem with this theory is that in both 30 & 31 bit record locking, real live records used the 1GB section of the file for large files. As a file grew to be very large, there was a section between 1,000,000,001 and 1,073,741,824 that was used by both the virtual locks and the actual records.

This caused a very strange ERROR 4233 where locking a record on 1 workstation, would cause an error reading an available record on another workstation.

In order to properly support multi-user record locking on files over 1GB in size, you should use BR 3.92i or greater.

Versions 3.92i and greater support a new Option (config). (4.03 and greater for 64 bit locking)

OPTION 33 { 30 | 31 | 32 | 64 } (default is 31)

Option 30, or 2**30 provides for 2**30 or 1GB (1,073,741,824) maximum bytes in a data file.
Option 31, or 2**31 provides for 2**31 or 2GB (2,147,483,648) maximum bytes in a data file.
Option 32, or 2**32 provides for 2**31 or 4GB (4,294,967,296) maximum bytes in a data file.
Option 64, or 2**64 provides for 2**31 or 17,179,869,184GB 18 Quintillion (18,446,744,073,709,551,616) maximum bytes in a data file.

• Note: There is a 2**31 limit on the number of records in a Business Rules Table.
• Note: 30 bit locking should be selected to be compatible with CIFS / SMB products like Samba and SCO Vision.
• Note: 32 bit locking requires a 32 bit OS such as (NT/W2K/XP/Vista/2003/2008)
• Note: 64 bit locking requires a 32 bit OS such as (NT/W2K/XP/Vista/2003/2008)
• Note: 64 bit locking requires the Netware Client for Windows on a Novell Network.

The virtual record lock formula was also changed. Now instead of using a starting value, and increasing by one, record 1 now uses the last possible value for the table, and then each record counts backwards.

To provide a reference, 30 bit record locking will behave as follows:

Instead of locking record 1, record 1,073,741,824 is locked.
Instead of locking record 2, record 1,073,741,823 is locked.
Instead of locking record 3, record 1,073,741,822 is locked.
Instead of locking record 4, record 1,073,741,821 is locked.

As you can see, the true limit of actual available records is a bit smaller than the actual mathematical limit. 2**XX - (# Records)

The following table should give you "Safe Limits" for each of the options.

30 bit locking gives access to about 1 GB. (Compatible with Samba)
31 bit locking gives access to about 1.8 GB. (All "DOS/Windows" Environments)
32 bit locking gives access to about 3.6 GB. (NT/W2K/XP/Vista)
64 bit locking gives access to about 17,179,869,100 GB. (NT/W2K/XP/Vista)

BR will not start two sessions using different lock bit requirements.

A message box is produced when that is attempted.

Enhancements

BR 3.8 uses 31 bit locking. BR 3.9 heretofore used 30 bit locking to be compatible with CIFS / SMB products like Samba and SCO Vision. However this has proven to be an unacceptable limitation because files that are greater than 1 gigabyte can get random locked records for no apparent reason.

As of release levels 3.92i/4.02i/4.12i, 31 bit locking is the default.

This will take you to prox 1.8 GB without locking conflicts.

32 bit locking gives access to about 3.6 GB.

Release 4.03 or 4.13 is required to go to 64 bit locking, but this is not possible on Windows 95, 98 and ME.

Abnormal Termination Error Logging

A new logging capability is provided for handling BRSERVER failures. An error log file in the BRSERVER directory is appended to when a BRserver process is abnormally ended. Also, a client msgbox is displayed when an assertion failure or program crash occurs. On Unix systems, the system error log is also updated. Keepalive failures are also logged here.

NOTE: It is very useful to, under Windows, RUN DRWTSN32 -I. This will set DR Watson as your default application debugger. There is no way for BR to trap some errors under Windows. However, if DR Watson is activated we can tell a lot from the logs produced by Dr. Watson at the point of error.

Also running DRWTSN32 with no flags places it in a menu driven mode that can enable you to override the Dr. Watson log file directory.

Other Notes

• Large file support on Unix/Linux is currently being researched.
• BR will not start two sessions using different lock bit requirements, and a message box is produced when that is attempted.
• The record locking mechanism was substantially revised to enable record locking

without actually locking records. This allows report writers and ODBC to access locked records without interference.