Utility method should wait till some other process in progress

Question

Question

prashanth ponugoti · Mar 3, 2023

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.

Thanks,

Prashanth

Product version: IRIS 2021.2

Discussion (7)1

Log in or sign up to continue

Robert Cemper · Mar 3, 2023

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.

0 0

score 0 · Answer 1 · 2023-03-04T11:50:09-05:00

Alexey Maslov · Mar 4, 2023

Robert,

I guess you meant Lock +^myReload

0 0

score 0 · Answer 2 · 2023-03-04T06:26:08-05:00

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.

Cheers,

Alex

score 0 · Answer 3 · 2023-03-04T11:53:14-05:00

> This avoids the need wait with locks / blocking

If so, why the common practice is to write something like this:

 tstart
 lock +^smth
 set ^var1(x1,...xn)=...
 ...
 set ^varN(x1,...xm)=...
 lock -^smth
 tcommit

score 0 · Answer 4 · 2023-03-04T12:41:48-05:00

Hi Alexey,

Thanks for question on clarification.

The suggestion on the transaction was to avoid needing to lock and block by read processes.

Yes, it makes sense to have a lock, with timeout, and success test on the update process, if there is logical chance of multiple operations updating the reference table.

Hope that makes sense.

score 0 · Answer 5 · 2023-03-04T13:58:04-05:00

The suggestion on the transaction was to avoid needing to lock and block by read processes

Hi Alex,
How can transactions help to avoid locking/blocking by read processes if they need to see a consistent database state, taking in account well known fact that transactions are not isolated in IRIS?

score 0 · Answer 6 · 2023-03-05T04:53:42-05:00

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.