Colleague: Registration/Billing error: Student records are being updated by another process

Sometimes a lock shows up when running a process that touches AR records like BILL or RGN, but there is not record lock.  This could be a soft lock created by information stored in AR.LOCKS.  This is discussed in Ellucian's article 6776

https://elluciansupport.service-now.com/customer_center?sys_kb_id=d05fb84e47b62510befa0775d36d43c4&id=kb_article_view&spa=1

Description: The following error is encountered during registration:
"The records for student \1 (\2) are being updated by another process.  Please try again later."
or
"The records for student \1 (\2) are being updated by another process.  Either try to save again or cancel your changes."

NOTES:

Informaiton: 

First, it's important to understand that this error message is normal and expected: locks are created for very good reasons. This error is likely to come up during heavy registration periods. The question is whether or not they are legitimate.

Instinct might drive an administrator to check for database locks but they will not find any.
This is because the lock referred to by the error is a virtual lock.
RGN tries to acquire a lock for each student record being updated and if it cannot get a lock will issue the error message AR291 (ST.ERROR).

To do this, RGN executes subroutine S.ACQUIRE.AR.LOCK which determines if there is a record in the AR.LOCKS entity for a particular PERSON/STUDENT record. The AR.LOCKS entity contains records representing virtual 'locks'.
Within each record there are several pieces of important data tracking where the lock is coming from.
These include the time of the lock, the user executing the process, the mnemonic and process ID.

++++++
NOTE: These fields are AR.LOCKS.CHGDATE, AR.LOCKS.CHGTIME, AR.LOCKS.CHGOPR, ARLK.PROCESS.MNEMONIC, ARLK.PROCESS.PID.
++++++

If S.ACQUIRE.AR.LOCK sees a process ID already in the record (ARLK.PROCESS.PID), it will issue that error message. From the AR.LOCKS Colleague Technical Reference:

'When a process wants to reserve the object for the specified reason, it examines the ARLK.PROCESS.PID field. If empty, then no other process is using that object. The process stamps its PID on the record. When the process is done with the object, it erases its PID from the record.'

Examining the AR.LOCKS records will give an indication of where the locks are coming from. Usually these locks are coming from the BILL process or from students trying to register online or from an advisor trying to register their advisee. Usually these locks are legitimate, sometimes they're leftover. If the administrator determines that the virtual locks are no longer legitimate they can clear out the AR.LOCKS entity and move forward.  Typically, locks older than 24 hours are safe to remove however, it is always best to contact your administrator.  

++++++
NOTE: See defect 47706.25 for an example of how BILL/RGN combinations cause undesired results.
++++++

**************************************************
NOTE: The steps shown below use the colon prompt. All non-Saas clients have access to the colon prompt, regardless of database. See the article below on how to access the colon prompt. Or, use the second article listed below with instructions on checking & clearing locks in SQL.

3084 - How to get to the colon prompt in R18 now that SHEL is gone
5834 - How to find and kill a SQL lock


Example:

A user is getting error message about student 0019406. Querying AR.LOCKS does reveal a record for student 0019406. The following fields: AR.LOCKS.CHGDATE, AR.LOCKS.CHGTIME, AR.LOCKS.CHGOPR, ARLK.PROCESS.MNEMONIC, ARLK.PROCESS.PID determine who, what, and when that lock was created.

:ELE AR.LOCKS 0019406*REGBILL -DICT
6 lines long.

>>>>: P
0001: ARLK.PROCESS.PID....: 25068
0002: ARLK.PROCESS.MNEMONI: RGN
0003: ARLK.LOCK.LEVEL.....: 1
0004: AR.LOCKS.CHGOPR.....: AYH
0005: AR.LOCKS.CHGDATE....: 15412
0006: AR.LOCKS.CHGTIME....: 50693
Bottom at line 6.


This example shows us that user AYH was running RGN and that process ID was 25068. The next step would be to determine if process 25068 still exists or not. We could check the AR.LOCKS.CHGDATE and AR.LOCKS.CHGTIME values to see if they make sense: are they from a week ago or just seconds ago? Lastly, we can contact AYH and ask them if they're currently registering the student or not. Based on this information we can determine whether or not this virtual lock is legitimate and either leave it be or clear out the record.

Some examples of processes that write out locks to AR.LOCKS:

WRGS (Register and Drop Sections)
RGN (Registration)
BRGN (Block Registration)
SECT (Sections)
BILL (Batch Reg/Room/Meal Billing)
WCEN (Electronic Card Entry)
WBSTS027H (Pay for Classes)

For more detailed information and information on how to go about troubleshooting these locks review the Colleague Technical Reference for the following items: AR.LOCKS, S.ACQUIRE.AR.LOCK, and S.RELEASE.AR.LOCK. The Colleague Technical Reference contains a lot of information on the whole locking process and will empower users to troubleshoot these issues quite effectively.

 

Here is a sample query that could be used to investigate and then if needed, remove records.  You should not need to remove records unless there is something in ARLK_PROCESS_MNEMONIC and ARLK_LOCK_LEVEL is greater than 0.  Make sure there is not a legitimate processes creating the lock before deleting any records.

-- check ARLK_PROCESS_MNEMONIC to determine the process that created the lock
-- check AR_LOCKS_CHGOPR to see who was running the process
-- check AR_LOCKS_CHGDATE to determine when the lock was created.
-- ARLK_PROCESS_PID shows what process is running and can be used for further research. If empty, then no other process is using that object.
-- Look at ARLK_LOCK_LEVEL, is it something other than 0. A process can call many subroutines, and it may be the case that more
--     than one of these subroutines needs to lock the same object.  For this purpose a 'lock level' is maintained.  Each time the same process locks
--     the object, the lock level is incremented.  Likewise, releasing a lock causes the lock level to decrease.  This gives the effect of 'stacking'
--     the locks and prevents a lower-level subroutine from fully releasing the lock before a higher-level subroutine is completely finished with
--     the object.  The value in ARLK.PROCESS.PID is erased only when the lock level reaches 1.

--Select AR_LOCKS AND DELETE
WITH DelARLock AS (
SELECT * FROM AR_LOCKS
WHERE ARLK_LOCK_LEVEL > 1)

SELECT * FROM DelARLock ORDER BY AR_LOCKS_CHGDATE DESC,AR_LOCKS_CHGTIME DESC

--DELETE FROM DelARLock

 

 

 

 

 

Print Article