Question
· Oct 11

How do I trace low-level deadlocks between globals, SQL tables, and object transactions across mirrored IRIS instances?

We're encountering occasional deadlocks in a mirrored IRIS deployment. How can we track down which global or object write caused the lock cycle, and how does IRIS mirror lock propagation internally?

Discussion (1)1
Log in or sign up to continue

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.