Yes, that's true ..:-)
In order to find the deadlock monitoring the onstat -k output with onstat
-x and onstat -u output will help ...:-)
The owner of onstat -k will map to the session of onstat -u output.
Not much of an help ..:-) but you would require to do some combinations of
the above to track the session which is causing the DEADLOCK.
Advisory Support Engineer(Wells Fargo Bank)
IBM Software Group -- Data Management
Ph: 602-2172100, Fax: 602-2172100
Sent by: cc:
owner-informix-li Subject: Finding source of deadlock
Please respond to
It's the classic SQLCODE -243/ ISAM -143 deadlock error (I typed those
numbers from memory, so I hope they're correct).
We recently modified a program and it started sporadically getting this
error on an OPEN cursor statement.
The coder thinks the program is deadlocking against itself (meaning it's
own transaction - not another instance of the same program).
I don't even think that's possible. (1st question: Is it even
Of course, this never showed up during QA on our non-production box, and
when we rerun it, it has always completed.
This is enough evidence for me to leap to the "wild" conclusion that it
is deadlocking against some other process.
2nd question: Is there any way to trap information about who caused us
If memory serves me, when Informix detects a deadlock situation, it send
an error to 1 process and allows the other process to go on its merry
Thanks in advance,