· Mar 3, 2023

Utility method should wait till some other process in progress

Hi Friends,

I have created one utility method to check given id exist some reference table or not. If exist the method return1 otherwise 0.

But some times the backed table data will be reload with another process (REST request) , on any point of time. This reload process max it will take 30 seconds.

My Requirement is , the utility method should wait , if table reload is in progress.

Could you give me any suggestion for this issue.



Product version: IRIS 2021.2
Discussion (7)1
Log in or sign up to continue

If you are not afraid of using basic COS functionality:
your reload method raises a LOCK ^myRELOAD  
and drops it with completion LOCK -^myRELOAD

Your check utility does the same but with a timeout LOCK ^myRELOAD:0
if it fails - signaled by $TEST=0  you loop and hang around and retry
for success $TEST=1 you go on but release your successful LOCK immediately
not to block anyone else.

Hi Prashanth,

This scenario did remind of some experiences with dynamically loading data in previous jobs.

So will make a suggestion to consider whether "utility method waiting" is the best approach.

At the beginning of the reload of reference table you could use "TSTART".

Then at the end of reload of reference table you could use "TCOMMIT".

This means ALL other processes accessing the reference table get a consistent Version1 or then Version2 of the reference table.

This avoids the need wait with locks / blocking, as other processes don't need to wait for the loading process to complete or even be aware of when the reloading process is working.

One other suggestion (which you may already have undertaken) is:

If you delete ALL the reference data and then add it ALL back for a small number of record changes, it can cause a unnecessary activity in Journals.

Instead, if you only remove unwanted records, add new records and update changed records, this can minimize activity in Journals for the reference table. ie: Where most reference table records are unchanged you could get better performance.

Hope this helps.



Hi Alexey,

Atomic read of a single global node.

In the questions example, the reference table can use a single global node.

Use cases are lookup table and application code tables (SELECT %NOLOCK ...)

Conversely for reading complex records spanning multiple global nodes, then yes the lock is needed for consistent full read:

1) During the full read

2) Just before the commit of the transaction from updating process.

However this is also much less than blocking for the full 30s seconds described in original scenario.