When a Thread Can Be Suspended

When a thread fails, the database server can perform a set of tests to determine whether it can safely suspend the thread. The thread must meet these requirements:

• It must not be a member of a class of threads that are critical to the database server. For example, secondary session threads (x_exec_*) are critical to database server operation and cannot be suspended, but parallel sort threads (psortproc) are not critical and can be suspended.
• It must not be holding a shared resource, such as a mutex.
• It must not be in a critical section.

If the thread meets these requirements, the database server can suspend it. When the database server suspends a thread, it also rolls back any work that the thread has performed and sets appropriate alarms.

If the suspended thread is the primary session thread of the client, such as the sqlexec or onutil thread, the client is disconnected. If the suspended thread is not the primary session thread, the client remains connected to the database server and can start a new transaction. If the suspended thread was processing a transaction, the transaction is rolled back globally after the thread is suspended.

The client receives the following two error messages.

Number

Message

-959

The current transaction has been rolled back due to an internal error.

-172

ISAM error: Unexpected internal error.

If the database server cannot suspend a thread that has failed an assertion, it writes an appropriate message to the message log before it shuts down.

For information about identifying threads that have been suspended and removed, refer to the examples of onstat output in Examples of Suspended Thread Output. For information about what to do if processes incur suspended threads, see Reporting and Clearing Suspended Threads.