1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
<!DOCTYPE HTML PUBLIC>
<HTML>
<TITLE>Xbase DBMS Chapter 12</TITLE>
<BODY BGCOLOR=#FFFFFF>
<H1><p align="center">Record and File Locking</p></H1>
<p align="center">Chapter Updated 12/13/22</p><hr>
<h3>Locking Overview</h3>
Xbase64 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.<br><br>
Automatic record locking is on by default in the Xbase64 library. To disable it,
use method xbXBase::DisableDefaultAutoLock() and to enable it, use method xbXBase::EnableDefaultAutoLock().
<br><br>
Locking can also be enabled / disabled at the table level with with xbDbf::SetAutoLock().<br><br>
If autolocking is disabled and the code base is being used in a multi user environment, it is
up to the application program to verify the needed locks are set as there is no checking or
setting any locks if autolocking is turned off. It is only safe to turn off the autolocking functionality
if the library is being used in a single user environment.
<br><br>
The current Xbase64 record locking logic is modeled after DBase (tm) V7 locking.
<br><br>
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
<em>errno</em> or function <em>perror()</em> can be executed to view the
results.
<br><br>
The errno field may contain one of the following values if the lock was not
successful.<br><br>
<TABLE BORDER>
<TR VALIGN="BASELINE">
<TR><TH ALIGN="LEFT">Error Code<TD>Description
<TR><TH ALIGN="LEFT">EBADF<TD>Invalid file descriptor
<TR><TH ALIGN="LEFT">EINVAL<TD>Invalid lock information or file does not support locks
<TR><TH ALIGN="LEFT">EACCESS<BR>EAGAIN<TD>Lock can not be set because it is blocked by an existing lock on the file.
<TR><TH ALIGN="LEFT">ENOLCK<TD>The system is out of lock resources, too many file locks in place.
<TR><TH ALIGN="LEFT">EDEADLK<TD>Deadlock condition
<TR><TH ALIGN="LEFT">EINTR<TD>Process was interrupted by a signal while it was waiting
</TABLE>
<br><br>
<h3>Linux/Windows File Locking Compatibility Issue</h3>
There is a compatibility locking issue to be aware of. Windows environments allow for the exclusive
opening of file handles and Linux/Unix platforms do not. If you are writing an application that will be
using a tool like Dbase on a Windows machine, accessing a file on a Linux/Samba configure machine,
be aware that the file could be opened in exclusive mode by DBase on the Windows system, and the same file could
be simultaneously opened with a program on the Unix box. That could cause some issues.
<br><br>
In Unix, a program can not lock a file so another process can not access it.<br>
In Windows, a program can lock a file so another process can not access it.<br>
DBase(tm) supports routines to open files exclusively, preventing other users from opening a file.<br>
Locking on the Mac/Apple platform only works on NFS shares. It does not work with SMB shares.
<br><h3>Samba settings</h3>
If you will be using Samba on Linux/Unix and sharing files between Linux and Windows machines,
you will need to disable oplocks. In the smb.conf file, set:<br>
<br>
[sharename]<br>
oplocks = False<br>
level2 oplocks = False
<br><h3>iLockFlavor</h3>
The library was constructed in a manner so that it could be updated to support alternate lock "flavors".
The 4.x.x library is built to mirror the DBase locking, but the structure is in place to expand to other locking
types if needed.
<br><br><br>
<hr><br>
<p><img src="xbase.jpg"><br><hr>
</BODY>
</HTML>
|
