Lock Types view

Administration DBA Lock Types Lock Types view

The Lock Types view displays the system (built-in) and user lock types defined for your site. A lock type controls and prevents the concurrent execution of some processes in N4. For example, at any given time, only one process must be executing to select a lane in the same ASC transfer area; otherwise, there is a risk that they may pick the exact same transfer lane sending more than one truck to the same lane. To prevent this, N4 has provided built-in lock types for standard N4 processes to ensure that such processes do not run concurrently, even across a multiple server installation. If N4 locks a row in the database for a process, N4 releases the lock when that row in the database is committed. N4 does not allow you to delete a built-in lock; however, you can modify the built-in lock’s description and wait time.

N4 provides the following built-in lock types at the facility level to prevent more than one concurrent process from selecting:

A lock type specifies:

An administrator can use the Lock Type form to edit the built-in lock types, such as to fine tune the timeout value. Groovy programmers can use the Lock Type form to add additional lock types and edit and delete those lock types, as needed, for use in their Groovy code.

When defining a lock type for your Groovy code, you need to:

In addition to the uniqueness by scope, there are cases where you need to define an additional uniqueness so that the lock type is more fine grained. For example, when selecting a container for delivery by bill of lading, it is ok to have concurrent processes for the other bills of lading but not for the same bill of lading. To support granularity at this low level, you can pass a qualifying string to the Lock Provider. In our example, you could pass the BL Number to the Lock Provider to specify the granularity of the lock by bill of lading.

When defining the uniqueness of a lock type, it is important to define the right level of granularity. For example, a lock type to lock concurrent processes from selecting an empty container at the facility level does not require an additional qualifying string. In another example, a lock type to lock concurrent processes from selecting an exchange lane at the complex level with an additional qualifying string by transfer zone ID can result in N4 creating unnecessary locks, if the complex has more than one facility with the same transfer zone ID. In this case, the lock type should be defined at the facility level.

When trying to acquire a lock, if a row does not exist in the database that matches the uniqueness of the lock type, N4 inserts and commits a matching record in order to acquire the lock. Therefore, Navis recommends that you try to create locks early in the Groovy process.

In addition, you can use the Actions menu to:

 

Lock Type Columns

Short Label

Long Label

In Filter?

Sorting?

Changed

Changed

X

X

Changer

Changer

X

X

Created

Created

X

X

Creator

Creator

X

X

Description

Description

X

X

ID

Lock Type ID

X

X

Life Cycle

Life Cycle State

X

X

Scope

Unique By Scope

X

X

System

Built In

X

X

Wait

Wait

X

X