interbase.interclient
Class DeadlockException

java.lang.Object
  |
  +--java.lang.Throwable
        |
        +--java.lang.Exception
              |
              +--java.sql.SQLException
                    |
                    +--interbase.interclient.SQLException
                          |
                          +--interbase.interclient.DeadlockException

public final class DeadlockException

extends interbase.interclient.SQLException

A deadly embrace between two transactions has occurred in which both transactions are waiting for each other to terminate.

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.

The error code associated with this exception is isc_deadlock from the InterBase ibase.h file.

Since:

Extension

See Also:

Serialized Form

Methods inherited from class java.sql.SQLException

getErrorCode, getNextException, getSQLState, setNextException

Methods inherited from class java.lang.Throwable

fillInStackTrace, getLocalizedMessage, getMessage, printStackTrace, printStackTrace, printStackTrace, toString

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait