Currently, most of the locking conflicts in Elliott come from user going to item or customer file maintenance change mode. User keep the change record on the screen without releasing it. This can happen when the user is interrupt with a phone call, or has to take a break. This however, causing extensive locking for other users who need to update the item or customer record and wait have to wait in the locking loop until this record is released.

It is suggested that we should consider implementing phantom locking on Item and Customer in the change mode to avoid locking conflict. Just as an example, the phantom locking for item table work as following:
(1) User bring up item A in item file maintenance change mode. Traditionally, the item A will be locked at this moment. With phantom locking, there's no lock on item A. However, we will keep a copy of the record A as the original value.
(2) User 1 change the item A and save it. However, before saving it, system will read item A with lock, then compare if the record is different with the original value.
(3) If the record value is the same, then system will proceed with the change and save the record, and release the lock.
(4) If the record value is not the same, then system will warn user that the record had been changed by someone else while trying to change the record and retry it again, and release the lock without making changes.
(5) Since the time it takes from (2) to (3) or (4) is only a split of a second (because there's no users interface), the locking burden is minimal which will greatly reduce the potential locking conflict.

In theory, all master file maintenance can create a locking conflict stated above. But, base on our experience, so far the areas that more likely to cause the conflict is customer and item file maintenance. Therefore, we suggest to address these two areas first. Let us know if you are interested for us to support something like this.