Deadlock Errors - Attach Hangs
This condition may be characterized by a gds_lock_print showing at least one deadlock and attempts to attach hang. This can occur when system resources are exhausted. Here's some things to check for.
- Check /usr/interbase/interbase.log for semaphore or shared memory errors. If errors are found, up kernel configuration.
- Check the number of gds_inet_servers owned by a single user. The system could be exhausting the maximum number of simultaneous processes allowed for a single user (specified by MAXUP). It appears that the lock manager will allocate a process block but the gds_inet_server will be unable to start resulting in a deadlock state.
- Check if the user is using or blocking signals SIGUSR1 or SIGUSR2. This could be interferring with InterBase's use of these signals.
Deadlock Errors - Process Hangs and Deadlock Errors
In the standard concurrency wait transaction model, if transaction A writes to a record and then transaction B attempts to write to the same record, transaction B will wait indefinitely until transaction A completes with either a commit or a rollback. For example, in two qli sessions type "for states modify using area=12"
If transaction A commits, then transaction B will fail with an update conflict. In such case, transaction B should always have an error handler which handles the failure by either rolling back and restarting the transaction, or committing and then exiting.
If transaction B's error handler commits in the error handler of an update conflict then the transaction is not atomic since the conflicting updates will not be committed but other updates will. This approach is not recommended. Rather it is better to rollback in error handlers.
Deadly embrace occurs when transaction A is waiting for transaction B to complete and transaction B is waiting for transaction A to complete. This can be produced in 2 qli sessions with:
transaction A: "for states modify using area = 100", then transaction B: "for cities modify using altitude = 1001", then transaction A: "for cities modify using altitude = 1000", then transaction B: "for states modify using area = 101"
At this point both transactions are waiting for each other to complete. This will be detected by a deadlock scan which is performed automatically about every 10 seconds. One of the transactions will fail with a deadlock, the other keeps waiting until the error failing transaction's error handler either commits or rolls back. If the failing transaction commits then the other transaction will fail as well with update conflicts. If the failing transaction rolls back then the other transaction resumes.
In summary, update conflicts can wait indefinitely. Real deadlocks are detected by deadlock scans, but unless the process which receives the error rolls back, one process may hang indefinitely.