Release System Locks
Hi Guys,
We currently for reason I'm getting too many locks in the system (around 990 locks) and is making the system slow
most of these locks are on globals
I have a method that sets values in some globals every minute which I guess will place a lock on each one and expecting the system would just automatically release them afterward, use to be fine before but for some reason now the list of locks keeps growing, so is there way to just release the lock after setting values in my globals because I don't need them locked anyway?
Thanks
Product version: Ensemble 2018.1
Hi Rochdi,
If directly working with globals in a live system, I would strongly advise you to use the LOCK command to set and release locks. It is possible that if your process has not stopped, all the locks are still being retained.
Documentation: https://docs.intersystems.com/iris20232/csp/docbook/Doc.View.cls?KEY=RCO...
Consider using the following from the documentation:
Additionally, using LOCK without arguments, will release all active locks in the namespace held by the current process.
Thanks, I've applied the following which I'm guessing it should release the each lock after 2 secs but as I checked in management portal the some locks are still there for the last couple of hours, so am I missing something?
I see you're locking the global +^IudexNqlInByte not unlocking. can you check the below
tstart if staten["IUDX" { lock +^IudexNqlInByte(1):0 if $test{ set IudexNqlInByte(1,inc)=obj.%Id() lock -^IudexNqlInByte(1) } } else { lock +^ToshibaNQLIn(1):0 if $test { set ^ToshibaNQLIn(1,inc)=obj.%Id() lock -^ToshibaNQLIn(1) } } tcommit
I thought that tcommit will delete the locks ?
I think I tried deleting lock using lock -^Myglobal before and didn't work even from the Terminal will try and see
Thanks Ashok
Basically. The tcommiit will commit the current open transaction. Lock -^global (decremental lock ) is used to release the incremental lock( lock +^global) so everytime if you do incremental lock then you should decrement the lock) by using lock -^gbl syntax
Argumentless lock is release all the locks in the process. So this is not highly recommend in code. And incremental locks are highly recommend for use.
Yes but the thing is that even deleting the lock from Terminal doesn't seems to work
Deleted lock for ^AlliedOneNQLIn refreshed the locks page and all the locks are still there ?
even deleting the lock from Terminal doesn't seems to work
Whatever you try to express doesn't make sense
Any kind of LOCK is bound just to the job that executes it
there is just no "UNLOCK" from outside except job termination.
the locking job in your screenshot is 9908
but your terminal is job 10376
expressed in a picture:
- you try to catch a fly in your room that is flying somewhere outside the building
I recommend using two terminals to experiment with locking and unlocking various globals. By observing the lock table during this process, you'll gain a clearer understanding of lock behavior across different processes.
Next, consider what you're aiming to lock. In other words, identify what you're trying to safeguard and against which potential issues. For instance, is the variable "loc" unique? Could two processes obtain the same value for "loc"? Without seeing the preceding code, it's challenging to discern if "loc" was assigned manually or via `$Increment`. Remember, using `$Increment` eliminates the need for locks in most cases.
Also, reevaluate your decision to use transactions for a single global write. If your goal is transactional integrity, think about which additional global writes should be encompassed in that transaction. For example, if "obj" is defined just before this code with a `%Save()` method, then include that save in the same transaction. Otherwise, a system interruption between the two actions can lead to an unindexed object, compromising data integrity.
I strongly advise revisiting the documentation multiple times and actively experimenting with these concepts. While these techniques offer significant advantages, their efficacy diminishes if not executed properly.
The lock is belongs from different process(9908) and you're trying to terminate via different process(10376) not is not possible. You can verify and terminate the 9908 in process (System Operation>Process) if no longer required for prevent multiple locks set again and click remove all locks for process and remove it.
Sorry Ashok this code didn't work, my globals could set at all maybe because in the code it's locked before been set, will put some traces and see where it's stopping
tstart if staten["IUDX" { lock +^IudexNqlInByte(1):0 if $test{ set IudexNqlInByte(1,inc)=obj.%Id() lock -^IudexNqlInByte(1) } } else { lock +^ToshibaNQLIn(1):0 if $test { set ^ToshibaNQLIn(1,inc)=obj.%Id() lock -^ToshibaNQLIn(1) } } tcommit
Hi Rochdi,
As mentioned, always ensure locks are explicitly released after use.
Reading between the lines a little, you might find these following points useful...
$Increment()
is useful for creating sequenced ordinal ID's that are always unique, without the need for locks. This is true for high-concurrency solutions.(If you're using locks only to make the key "inc" unique, then consider using
$increment
and forgo the locks.)