Locking properties

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 setting of nolocking.

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: Apr 15 2024
Copyright © 2024 Thunderstone Software LLC. All rights reserved.