|
|
If a KSAM file is shared with another process, you need to ensure that the
most current data and key index information is retrieved. Locking files
controls other processes from accessing the file while a modification routine
is processing. Such a modification routine should include the pointer
positioning and reading routines that are associated with the modification
routine. The FUNLOCK intrinsic allows the file to be shared again,
once modifications are complete.
In a shared environment, it is recommended that you lock and unlock the file
for pointer-related activities, such as FREAD or FUPDATE
intrinsics using FFINDBYKEY or FFINDN intrinsics to locate
the proper record.
 |
NOTE: File locking keeps the file inaccessible to other users
for an indeterminate length of time. This could be a potential source
of performance problems. A different file structure may be more
suitable for applications in a shared environment.
|
The following example shows how modification routines can be locked effectively
by the placement of the FLOCK and FUNLOCK intrinsics.
FLOCK
FREADBYKEY
FUPDATE
FUNLOCK
FLOCK
FFINDBYKEY
FREAD loop
FUNLOCK
In many interactive processes, it is inefficient to keep a
file locked while a user retrieves a record, decides whether it
needs to be updated, makes appropriate changes, and writes the new
record. In such cases, a simple read could retrieve the record's
contents for the online user to see. Once a decision has been made
to modify the contents, a new retrieval redisplays the record for
updating. By rereading the file, the program will be able to verify that
the correct record has been retrieved without locking the file for
an excessive amount of time.
FLOCK
FREADBYKEY
FUNLOCK
.
.
.
Other users can access and modify this record while
the user decides how to update it.
.
.
.
FLOCK
FREADBYKEY
FUPDATE
FUNLOCK
|