eG Help

UniVerse record and file locks control access to records and files among concurrent user processes. To control access to records and files, UniVerse supports two levels of lock granularity:

Granularity refers to the level at which a process or program acquires a lock. Record locks affect a smaller element, the record, and provide a fine level of granularity, whereas file locks affect a larger element, the file, and produce a coarse level of granularity. Lock compatibility determines what a user’s process can access while other processes have locks on records or files. Record locks allow more compatibility because they coexist with other record locks, thus allowing more transactions to take place concurrently. However these “finer-grained” locks provide a lower isolation level. File locks enforce a high isolation level, more concurrency control, but less compatibility. Lock compatibility decreases and isolation level increases as strength and granularity increase. This may increase the possibility of deadlocks at high isolation levels. Within each granularity level, the strength of the lock can vary. UniVerse supports the following locks (in order of increasing strength):

The locks become less compatible as the granularity, strength, and number of locks increase. Therefore the number of lock conflicts increase, and fewer users can access records and files concurrently. Weaker locks can always be promoted to stronger locks or escalated to a coarser level of granularity if needed.

Whenever users complaints regarding data inaccessibility increase, it is good practice for administrators to check if too many file/record locks are being held, and if so, what their strength is. The UnivDBAcGrLkTest test provides administrators with this information, instantly! This test automatically discovers the types of locks currently active in the target UniVerse database and reports the count of locks held per type. From the lock types, administrators can quickly infer the strength of the locks. If too many strong locks are active on the database, then the detailed diagnostics provided by this test can be used to identify the processes holding the locks, the users who own the processes, and the file and records locked. This way, administrators can precisely isolate those processes that are unnecessarily holding the locks and can initiate measures to have those locks released.

Output of the test : One set of results for every lock type currently active in the target database. The table below discusses the probable lock types and what they represent:

Measurement

Description

Measurement Unit

Interpretation

lockCount

Indicates the number of active file/record locks of this type.

Number

Compare the value of this measure across types to determine the strength of the majority of locks currently held.

The table below discusses how each type of locks impact user access:

Lock type (strength)	Allows other users to acquire	Prevents other users from acquiring	Is ignored if the current user already owns
Shared file lock	Shared record lock Shared file lock Intent file lock	Update record lock Exclusive file lock	Shared record lock Update record lock Shared file lock Intent file lock Exclusive file lock
Update record lock	No locks	Shared record lock Update record lock Shared file lock Intent file lock Exclusive file lock	Update record lock Exclusive file lock
Shared file lock	Shared record lock Shared file lock	Update record lock Intent file lock Exclusive file lock	Shared file lock Intent file lock Exclusive file lock
Intent file lock	Shared record lock	Update record lock Shared file lock Intent file lock Exclusive file lock	Intent file lock Exclusive file lock
Exclusive file lock	No locks	Shared record lock Update record lock Shared file lock Intent file lock Exclusive file lock	Exclusive file lock