When more than one user is using Primecut at a time, the system must ensure that they don't "trample over each other's work". In order to do this Primecut uses Locking, whereby when a user is editing something, the system Locks the object being edited, preventing others from making changes to it. The locks are recorded in a table within the database which is continuously updated as objects are being edited and released.
You can think of locking an object (the object may be a part, a plate, a workorder or quotes, the costing data etc) as temporarily taking ownership of it.
Examples:
•If User A is nesting plate 123, we don't want User B to be nesting the same plate at the same time for example.
•If User A is editing the quantities on workorder line items, we don't want User B to be nesting those, as the quantities he's seeing are likely to change.
•We don't want User A and User B both trying to make changes to a part at the same time; if they did their changes might conflict, or whoever saved last would have their changes overwrite the other user's changes.
Cooperative Locking of Line Items
In Release 131 we have introduced the concept of Cooperative Locking in regard to Workorder line items. Previously when a workorder was edited, it would attempt to lock all its line items, and if any failed (for example someone my have been nesting one of the line items, thus had that line item locked), then you would be denied access to edit the workorder. With Cooperative Locking, the system does not attempt to lock any line items when a workorder is opened for editing, and instead attempt to lock the individual line items whenever a change is made to the line item itself.
There are options (right click context menu) to further control locking:
Refresh and Lock Line Items This is used to attempt to lock the selected line items. Be aware that the items are first refreshed from the database to get their latest state information.
Unlock Line Items to release unlocked items so that others may use them. If you have made changes to the line items you should first save the workorder. If the line items being refreshed have not been saved, you will be prompted whether to revert any changes- much like a refresh from database,
A Lock column has been introduced which shows the status of the line items locks, including a hover hint function which checks the database whether an unlocked line item is free to be locked, or is locked by another user in another session.
"Shared part" above was in use in nesting on another machine when this workorder was opened at 2:16:30 pm.
The orange text is another clue that none of these lines are locked here.
If the use hovers the mouse over that colum the locking table will be checked again, and the lock updated, as well as returning extra information about who has it locked and on which computer:
After hovering the mouse over the column at 2:19:11 pm, the suystem reports the part is being nested by "administrator" on the computer "Zeus3"
Note that if the other user with the lock releases it at some point while we have the parent workorder still open, it will still be showing as locked by the other user. However we can refresh the state of the lock column by hovering the mouse over it, or by trying to lock the line anyway; it will succeed if it can.
Now we lock a line item, either by double-clicking it, or by right clicking and selecting Refresh and Lock Line Items, or by editing its quantity or attempting to set any other property. If the lock succeeds (ie it hasn't been locked elsewhere in the meantime), the color of the txt in the line will change to the usual black:
One line item for discus675234 has now been locked
The system can be set up to use Greedy Locking by default, which is more similar to the pre Release 131 method: When a workorder is opened for editing, it will again attempt to lock all line items. Unlike earlier versions however, it will still allow you to edit the workorder and whatever line items it could lock (previous versions would only allow you to open the entire workorder in viewing mode).
Greedy Locking is recommended for single user scenarios (it may be slightly more efficient to work this way), or for when the programmer wants total control of the workorder he/she is working on always.
There is a Global Setting for Workorders which allows you to set the default Locking behaviour when a workorder is opened for editing; whether it should use Cooperative or Greedy Locking.
From the Tools Menu, you can select Monitor Locks, to show what is locked in the database (within tblLock). Locks are stored by locktype (part, workorder, workorderitem, plate etc), the ID of the locked row, and the sessionID owning the lock. Some locks may be held by cutting machines, these are indicated by negative numbers for the sessionIDs (they do not refer to normal Primecut sessions).
Additionally when you start Monitor Locks, it performs a check to see if there are any Dangling Locks, and gives you the user to purge them (recommended). A Dangling Lock is a lock whose parent session is no longer valid; it may have been killed by an administrator. See also Session Management.