Deadlock occurs when two transactions are holding locks that each block the other transaction from completing. When deadlock occurs, Ingres aborts one of the transactions, so that the other transaction can complete. The user whose transaction was aborted receives an Ingres error.

In a Vision application, deadlock can occur when the Locks Held on Displayed Data frame behavior is set to DBMS or shared locking for an Update frame. For example, deadlock occurs when multiple users hold a shared lock on the same data and each selects Save.

The Vision-generated code tests Ingres errors from the DBMS to see if deadlock has occurred. When Vision detects a deadlock error, it retries the transaction twice. If the transaction still cannot complete after three tries, the transaction is aborted.

By default, Vision tests for the generic error number, 49900. If your application uses DBMS error numbers, you must change the code to test for the DBMS error number, 4700. Change the value of the substitution variable $_deadlock_error, which is located in the intopdef.tf template file. You can also change the number of retries by setting the substitution variable $_deadlock_retry, also located in the intopdef.tf template file.

Vision does not hide the DBMS error message. The Vision application user sees the Ingres error message for deadlock. To hide Ingres errors from your application users, you must write your own error handler, and call it with the function IIseterr(). See the 4GL part of this guide for details.

See the Database Administrator Guide for more information about locking in Ingres.