jRLA

jRLA is an acronym for jBASE Record Lock Arbiter. The lock arbiter is responsible for resolving all record locking conflicts for jBASE processes. It runs in the background on your system and is commonly referred to as the lock daemon.

If jRLA is not loaded, jBASE will use the normal UNIX system locks. This is acceptable for small user populations, but the UNIX locking mechanism has limits on the number of locks available, and on performance.

Only enable the jRLA locking daemon when no other users are executing jBASE programs, otherwise some applications will use UNIX system locks and others will use the jRLA locking daemon.

In most situations a process will take and release locks autonomously and disregard both the lock daemon and other processes. However in certain situations it must inform the daemon of events or ask the daemon for permission. These situations only occur when there are clashes in locking such as when a process finds that a record is already locked or that another process requires the same lock.

 

JRLA COMMAND

Called as:
jRLA -a {-b}
jRLA -c {-o}
jRLA -d {-v} {-ffilename ...} {-ppid ...} {-L}
jRLA -i {-bmuEPT} {-sr,b,g} {-tnn}
jRLA -k {E}
jRLA -S

Option Meaning
-a attach to existing IPC resources
-b run in the Background (default)
-c clear the Lock Table
-d display the Lock Table
-ffile restrict the display option to file "file"
-i initialize shared memory and become the Record Lock Arbiter
-k kill the Lock Table and the Record Lock Arbiter
-m force jRLA to behave as a Multi-processor arbiter
-o override the "confirm you want to continue" message
-pnn restrict the display option to process id nn
-sr,b,n set lock table size to "r" record, "b" binary and "n" locks per group
-tnn set tidy up period to nn minutes
-u force jRLA to behave as a single-processor arbiter
-v verbose mode
-E errors caused by jPML and jRLA conflicts will be reported but ignored
-L display record locks
-P port based locks used (default is process id based locks)
-S force a tidyup now
-T time stamp all the locks

The jRLA daemon uses one of three possible locking implementations to control access to the record lock and binary lock areas, depending on platform and number of processors.

By default the number of record or item locks configured is 3000 and the number of binary or group locks configured is 601.

Daemons