AllAccepted answers
Vic Sun · Oct 16

Hi Jack,

Generally it can be a bit difficult to track lock issues because there is not an after-the-fact audit of locks. To answer a question like this would likely need additional context that the WRC (support) could help you collect. In my experience, this may involve setting up a script to collect lock snapshots over intervals so you can review problem periods and cross reference which processes are running at those times and taking those locks. This could involve running irisstat / SystemCheck.

I'm not sure I follow your question about lock propagation - is this a failover mirror or a reporting mirror? If a failover mirror, locking is irrelevant. The primary is sending sets/kills and the backup member has no independent ability to lock / make changes. If R/W reporting - that would be a situation I am less familiar with, though my suspicion is that as locks are stored in memory that they are handled independently on each node.

Vic Sun · Oct 16

Hi Jack,

IRIS locking works optimistically; the lock does not do anything in and of itself. It is the responsibility of other processes to attempt to take out a lock and/or verify if an existing lock has already been taken out. Shared locking would generally be used so that multiple processes can read a value at the same time while the values are not being modified. It may take consideration of the table architecture and an understanding of the general access patterns and what types of queries you are running to efficiently only lock what is necessary and not block modifications on a large scale.

It does feel like this is a small question that fits into a bigger project so there might be more to consider. I would recommend reaching out to your ISC contact / sales engineer to discuss this in larger scope.

Vic Sun · Jun 18

First thing that comes to mind is disabling TLS 1.1 as that is deprecated. For TLS 1.3 (if that's required) you'll need to migrate to IRIS ( being on Cache 2017 probably has other security implications that would be remedied by upgrading at least to Cache latest.)

You might be able to find out more about this issue using ^REDEBUG as discussed in another post on the community, else support can probably help look into what the issue is. It's been a bit since I've worked on something like this myself.

Vic Sun · Mar 12

Glad you found that interesting! One warning I can add is that if you do decide to add a "no-integrity" type purge and if you've never run one, depending on how many messages you have you may trigger a very large purge (and a lot of journaling activity as a result). Often times when making significant purge changes, it can be safer to increment the time period you are purging bit by bit to make sure you're not asking too much of a single purge.

ex. If you run daily message purges then every day you are purging 1 day's worth. If you have "expired" messages going back a few years and decide to purge them all of a sudden, that might be a surprising number.

Vic Sun · Feb 24

On a bit of a tangent but I might recommend reviewing the following post by my colleague and considering whether a 2 phase purge schedule would make sense for you. One purge task running as standard to clean up the completed messages and one running on a lag to catch any suspended / leftover messages that are old enough that you think they could be removed:

https://community.intersystems.com/post/why-keep-integrity-important-when-purging-healthshareensemble-data

Vic Sun · Feb 6

The journal does not contain the line of code (imagine needing to log that information for every single global modification), so to find the relevant code would require the type of cross referencing I suggested. The other option I would suggest would be to go through the program in the debugger. Especially if you have a general sense of where the relevant change would be made. But again, maybe the best option depends on why you are looking for this specific global set.

Vic Sun · Feb 6

Most likely more context on what you are trying to look up would be helpful to understand how best to approach this request. What occurs to me immediately is this might be a good case for involving the WRC to help investigate.

If you want to look into it yourself I think you would want to read through the journals to find the global set in question and what is being done around that set, then tracking from the process to what else it was doing at the time. You may need to have a SystemCheck / irisstat running in order to correlate the process to whatever routine it was running.