Locking

When operators repair payments, the payments are first locked for the user ID that accesses them. The automatic lock management of these locked payments may cause unexpected results. The automatic behavior prevents situations where items become locked to a user ID and never handled because the user does not repair the payments in a timely manner, possibly because of a system crash. Some scenarios that lead to automatic lock management are:

• A user receives a list of payments to repair and does not complete the repairs before the session times out. When the browser session times out, all items locked by the user are released for other users to repair. The pending payments for the user are automatically finalized after a session times out.
• A user receives a list of payments to repair and begins working in another area of the Control Center. Since the Control Center is in use, the session does not time out. A separate lock timeout, specified in the Maximum Lock Time property, may expire and release the payments with old locks for other users to repair. The pending payments for the user are automatically finalized when the lock timeout occurs.
• A user receives a list of payments to repair and logs out before repairing them. In this situation, the payments are released automatically as part of the log out processing. The pending payments for the user are automatically finalized after logging out.
• An administrator deactivates the priority control configuration while users are repairing payments. The system immediately unlocks all payments for all users in the system. When a user attempts to repair a previously locked payment, the following message is displayed: "Your repair was not accepted. PCC deactivation occurred causing pending repair items to be reset and locked items released. Please contact your administrator for additional details."

  When priority control configuration activation occurs, items can be retrieved using the get more items button. All pending repair items for all users are returned to the new state when a priority control configuration is reactivated. The reason this occurs is when the active priority control configuration is deactivated, it is handled as a stop all activity event by the repair system.