From 4875a3dd9b183dcd2256e2abfc4ccf7484c233b4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Frings-F=C3=BCrst?= Date: Wed, 7 Dec 2022 13:17:14 +0100 Subject: New upstream version 4.0.2 --- html/xbc8.htm | 130 ---------------------------------------------------------- 1 file changed, 130 deletions(-) delete mode 100755 html/xbc8.htm (limited to 'html/xbc8.htm') diff --git a/html/xbc8.htm b/html/xbc8.htm deleted file mode 100755 index efab841..0000000 --- a/html/xbc8.htm +++ /dev/null @@ -1,130 +0,0 @@ - - -Xbase DBMS Chapter 8 - -

Record and File Locking

Chapter Updated 2/1/99

- -

Locking Overview

- -Xbase DBMS supports multi-user processing through file and record locks. -Record locking restricts multiple cooperating programs from simultaneously -accessing the same data and corrupting it. Without record and file locking -in a multi-user environment, simultaneous access to the data and index files -can cause the files to become inaccurate and unusable.

- -Record locking is on by default in the Xbase DBMS library. To disable it, -comment out the XB_LOCKING_ON option in the options.h file in the -xbase/src directory.

- -The current Xbase DBMS record locking does not co-exist with other Xbase -products and there is not yet support for locking in a DOS/Windows environment. -The locking functions do work correctly for a Xbase DBMS only configuration. -Future version of Xbase DBMS will have enhanced locking features for -co-existing with other Xbase products and also include DOS/Windows support. -

- -The locking methods return either XB_LOCK_FAILED or XB_NO_ERROR. If they return -XB_LOCK_FAILED the actual reason can be found in the global variable -errno or function perror() can be executed to view the -results. -

- -The errno field may contain one of the following values if the lock was not -successful.

- - -

Error Code	Description -
EBADF	Invalid file descriptor -
EINVAL	Invalid lock information or file does not support locks -
EACCESS EAGAIN	Lock can not be set because it is blocked by an existing lock on the file. -
ENOLCK	The system is out of lock resources, too many file locks in place. -
EDEADLK	Deadlock condition -
EINTR	Process was interrupted by a signal while it was waiting -

-

-

Types of Locks

- -

Write or Exclusive Locks provide exclusive access to a -particular file location. No other process can lock the same location.

- -

Read or Shared Locks prohibit any process from requesting a write -lock on a specified part of the file. Other processes can request -simultaneous read locks.

- -

DBF File Locking Techniques

- -Xbase DBMS uses the following protocol for DBF file and record locking: -

- -To lock a record - the first byte of the record is locked.
-To lock the file - the header bytes of the file are locked.

- -When a record is being appended to the file, the header bytes are locked.
-When a record is being updated, the header bytes and the specific record are -locked.

-This locking protocol is probably not compatable with other Xbase type products. -However, Xbase can be safely used for multi-user access when it is not -simultaneously updating DBF or NDX files while other products/programs are. -

- -

NDX File Locking Techniques

- -Xbase DBMS locks indexes by locking the first 512 bytes -of the index file. -The entire index is locked because any updates to the index potentially -can modify significant portions of the index tree. -

- -

DBT File Locking Techniques

- -Xbase DBMS locks memo files by locking the first 4 bytes -of the memo file. This effectively locks the entire file. The entire file -is locked because any updates to the free block chain can significantly -change the structure of the file. -

- - -

AutoLocking Features

- -If XB_LOCKING_ON is set in the options.h file, the locking methods -execute any appropriate locking logic. If XB_LOCKING_ON is not set in the -options.h file, all locking methods return XB_NO_ERROR without -performing any actual record or file locking. This enables the application -program to always call locking routines regardless of the XB_LOCKING_ON switch -in the options.h file. -

-By leaving the autolocking features enabled, the application program does -not need to address record, file or index locking. All locking is handled -automatically by the Xbase routines. However, if access to the locking -routines is required, they are available to the applciation programmer. -

-When the files are automatically locked by the Xbase routines, the database -file is locked first, then it locks the indexes in alphabetical order. To -avoid deadlock conditions, files and record locks should always be done in -the same order. When the files are unlocked, then indexes are unlocked -first, then the database is unlocked. -

-Auto-locking works well in an on-line transaction based environment. -However, it does not function efficiently in batch mode. If you -will be writing programs which process files in a batch mode, disabling -auto-lock and locking the entire file at the beginning of the process -and unlocking the file at the end of the process will significantly -reduce process time. On a 586-200 class machine, a file with 45000 records -can be read thru in a few seconds with the file locked in batch mode. -In record-lock mode it takes about six minutes with the same processor. - -

For processing large files, locking the file instead of locking each -record is far more efficient. This is how you do it.

- -For reading the file in batch mode:
-xbDbf.AutoLockOff();
-xbDbf.LockDatabase( F_SETLKW, F_RDLCK, 0L );

-For updating the file in batch mode:
-xbDbf.AutoLockOff();
-xbDbf.LockDatabase( F_SETLKW, F_WRLCK, 0L );

-
-

- - -- cgit v1.2.3