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.

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.