|
<< Click to Display Table of Contents >> Paradox locks in depth |
  
|
|
<< Click to Display Table of Contents >> Paradox locks in depth |
|
Whenever launching a paradox application session (using the Paradox DBMS or some custom paradox application) the paradox system needs and auto creates a NET-file PDOXUSRS.NET - see also Paradox NET-file directory.
If needed the system also creates the locking files PDOXUSRS.LCK and PARADOX.LCK.
When more than just one application or application session is granted access to table records, a system of record locking is needed to prevent accessing conflicts. The BDE takes care of this without needs of locking files as long as every access goes through the BDE on a local computer.
As the working scope of the BDE, in essence itself being a desktop application, is limited to the local computer, accessing distant data files on another computer or on a network server raises the need for locking files visible also to other applications or to BDE sessions existing in their own memory space on other PCs.
Also, if running non-BDE data applications on the same computer accessing the same data, the BDE will need to create locking files to tell the system (DOS, Windows or network system) to take care of the table or record lockings.
Concerning the Paradox file locking feature via the BDE, this makes use of the operating system provided file locks or FLOCK(s) being a feature of most operating systems and for the PC world since the early DOS 3.3.
Record locking thus is a feature managed by the BDE and the operating system in cooperation.
For the purpose of this locking the BDE Paradox driver creates lock files whenever data resides on a distant location or when local non-BDE sharing is needed.
Thus, lock files are created by the BDE / Paradox driver only if not running in standard local data handling mode.
If not pre existing, the NET-file (PDOXUSRS.NET) is auto created as specified by the BDE-setting or by the application itself.
The NET-file keeps track of the current Paradox users from one or more computers pointing to that specific NET-file, and the NET-file may serve a number of data destinations as dynamically required.
The NET-file regulates data access, and if the data files are in a shared environment (e.g. on a network server or using local share - see below) the individual table and record access is regulated through Paradox lock files generated in the folders of the data table files.
The lock files in a data folder takes cares of every accessing user pointing to the same NET-file.
Traditionally the BDE as a default has been using the C:\ root location for this NET-file.
With introduction of Windows Vista (Windows 6.0) and later, writing data to the C:\ root location, or anywhere in the Program Files directory, is prevented by the operating system, and the BDE will not run unless this NET-file location has been re-specified for some other location. Respecting these exceptions the NET-file may be located anywhere on the local hard disk or even at some network location.
By default the BDE provides the afore mentioned fall back location of the NET-file.
However, it will be strongly recommended having the application to decide the location of the NET-file in use (in a per session mode), and this way to facilitate synchronized pointers to the same NET-file for cooperating applications using the same data and thus not depending on identical BDE NET-file settings on each connected computer.
If accessing distant data files as e.g. on a network server, the location of the NET-file should be located in a network directory visible to the other applications accessing the same data, and preferentially - but not necessarily - in the same folder as the data files.
The PDOXUSRS.NET file will persist when the data application(s) closes.
See also fall back vs. per session location of the NET-file in Paradox NET-file directory.
To maintain concurrency on a multi-user network for simultaneous application access, the applications must point to the same NET-file.
If the NET-file is located e.g. on a server \\SERVER_1\DATA:\Paradox\NetDir all applications must point to this same path, though it is accepted using different drive mapping for this same path as e.g. P:\Paradox\NetDir from one location and Q:\Paradox\NetDir from some other location, as long as the different drive mappings both point to the same path.
Paradox lock files exists in two flavours: the PDOXUSRS.LCK introduced and used since Paradox 4 for DOS and the old type PARADOX.LCK.
PDOXUSRS.LCK
This is the currently used type of lock file.
PARADOX.LCK
This is the type of lock file used with the protocol in use until before the advent of Paradox 4 for DOS (and database engine 3), which is not compatible with the PDOXUSRS.LCK files protocol used with Paradox 4 and since. To prevent old paradox applications from concomitantly accessing paradox tables controlled by the Paradox 4 locking protocol, the BDE in parallel creates these PARADOX.LCK files signalling exclusive access to prevent access from conflicting older applications.
Paradox lock files are created only if the data location is distant to the requesting computer (e.g. on at network server or on distant PCs in a peer-to-peer environment) or if having a BDE setting accepting local sharing with non-BDE applications (BDE / System / INI: LOCAL SHARE = TRUE).
Paradox lock files (if generated) are always located in the folder of the data files and communicates with the currently active NET-file, that often will be located elsewhere.
If all access to tables in a folder have terminated properly the lock files are deleted automatically.
Besides error messages evoked by users accessing distant data not pointing to the proper shareable NET-file (actually user errors rather than application errors), virtual errors may happen if applications are trying to open table files at the same moment that the last other user is closing down it's last access to any of the tables in the same directory. According to a Borland paper (now accessible through Embarcadero Developers' Network) this most often happens as the previous user is trying to close the lock file, rather than by the subsequent user trying to open some table and opening the lock file.
There are various solutions to this issue involving reprogrammed application modifications, which is however beyond the scope of this page.
Though, one simple solution is to create some "dummy" table (e.g. "Dummy.DB") in the network data directory along the proper table files and to keep it open all working hours, thus ensuring the BDE from various CPUs at any time will read this as at least one still active user (within working hours) and thus preventing the BDEs from trying to close the lock files as long as the still open Dummy table keeps the lock files busy.
Lock files left over for whatever irregular cause may prevent successive user access and manually deleting these lock files may be needed.
However, in a multi user environment, deleting old lock files should be done only with care to ensure that no one is currently using them. Deleting active lock files can produce unpredictable results and could cause loss of data.
The cause for left over lock files may also be due to local share limits, oplocks/caching, server I/O overload, OS limited file locks or file handles, application errors, system crashes, irregular software termination, unstable power supply, power failures or errors by the operating system for local system locking (FLOCK protocol) or of the network operating system. Tracing the specific cause thus sometimes may be hard to discover.
__________________________