These properties affect the way that locking occurs in the database engine.
Setting these properties without understanding the consequences can lead
to inaccurate results, and even corrupt tables.
- This will turn off locking completely. This should
be used with extreme caution. The times when it is safe to use this
option are if the database is read-only, or if there is only one
connection to the database. Default off. This replaces the prior
- This can be set to either manual or automatic. In
manual mode the person writing the program is responsible for getting
and releasing locks. In automatic mode Texis will do this itself.
Manual mode can reduce the number of locks required, or implement
specific application logic. In manual mode care must be taken that
reads and writes can not occur at the same time. The two modes can
co-exist, in that one process can have manual mode, and the other
automatic. Default automatic.
- Determines whether to use a portable or OS
specific method of sleeping while waiting for a lock. By default the
OS specific method is used. This should not need to be changed.
- How long to wait between attempts to check the
lock. If this value is too small locks will be checked too often,
wasting CPU time. If it is too high then the process might be
sleeping when there is no lock, delaying database access. Generally
the busier the system the higher this setting should be. It is
measured in thousandths of a second. The default is 20.
The lock sleep time automatically increments the if unable to get a
lock to allow other processes an opportunity to get the CPU. This
sets a limit on how lock to sleep.
It is measured in thousandths of a second. The default is 100.
Added in version 4.00.1016570000.
- Whether to be fair or not. A process which is running
in fair mode will not obtain a lock if the lock which has been waiting
longest would conflict. A process which is not in fair mode will
obtain the lock as soon as it can. This can cause a process to wait
forever for a lock. This typically happens if there are lots of
processes reading the table, and one trying to write. Setting
fairlock to true will guarantee that the writer can obtain the
lock as long as the readers are getting and releasing locks. Without
fairlock there is no such guarantee, however the readers will
see better performance as they will rarely if ever wait for the
writer. This flag only affects the process which sets the flag. It
is not possible to force another process to be fair. The default is
that it operates in fair mode.
- How verbose the lock code should be. The default
minimum level of 0 will report all serious problems in the lock
manager, as they are detected and corrected. A verbosity level of 1
will also display messages about less serious problems, such as
processes that have exited without closing the lock structure. Level
2 will also show when a lock can not be immediately obtained. Level 3
will show every lock as it is released. In version 5.01.1160010000 20061004
and later, the level can be bitwise OR'd with 0x10 and/or 0x20
to report system calls before and after (respectively). Levels 1 and
above should generally only be used for debugging.
In version 7.07.1565800000 20190814 and later, 0x40 and 0x80 may be
set to report before and after semaphore locking/unlocking.
- Stop in debugger when set. Internal/debug use available
in some versions. Added in version 4.02.1045505248 Feb 17 2003.
- Integer; controls debug malloc library. Internal/debug
use in some versions. Added in version 4.03.1050682062 Apr 18 2003.
Copyright © Thunderstone Software Last updated: Jun 1 2020