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:
APPT_TIME_SLOT: An appointment time slot.
AUTO_COMPLETE_LOCK: This lock type stops selecting a truck transaction when two truck transactions are processed at the same time, but through two different threads.
ECS_LOAD_SWAP_REQ: Lock per QC that will not interfere with the WI locks. Its timeout is configurable in the Lock Types tab, although the 5 second default should work for most customers.
EXCHANGE_LANE: An exchange lane when more than one work instruction transitions to Carry Underway at the same time.
GATE_APPT: A gate appointment.
PAYMENT_LOCK: This lock type prevents multiple payments for the same invoice when different users simultaneously post the same payment request API.
QA_DSCH_WA_DISPATCH: A work assignment.
RAIL_AUTO_STOW: If more than one user is trying to run N4 RAS (e.g. a gate clerk and control room clerk) this lock only allows one N4 RAS problem solver to assign a container to a single railcar position at a time. This lock is used when executing business task PlanUnitIntoYardOrRailcar.
SELECT_BARE_CHASSIS: A bare chassis.
SELECT_BKG_DRAYOFF: A dray-off container for the same EDO or booking.
SELECT_EMPTY: An empty container.
SELECT_IMPORT_BY_BL: An import container for the same BL.
TZ_DECKING: An exchange lane for the same ASC transfer zone.
UNIT_DISMOUNT: A unit dismount.
UPDATE_JSP: A work assignment that gets concurrent requests to update the job step projection.
YARD_PLAN: A yard position.
WORK_QUEUE_INIT:
A lock type specifies:
A unique ID and description for the lock type.
The scope over which the process execution is unique for this lock type. For example, selecting a yard position should be limited by facility because it is ok to have a concurrent processes searching for a position at another facility.
The time for which an instance of a process must wait to obtain a lock before terminating with an error.
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:
Use the Lock Type form to add a lock type.
Pass either the enum or Lock Type ID along with an optional qualifying string to the Lock Provider (LockProvider.setLock()).
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:
Recover Obsolete: Recover deleted lock types.
Purge: Permanently delete selected lock types.
Copy Reference Set: Copy lock types from another entity set.
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 |