Data store exclusive access

A messaging engine establishes a lock on its data store so that it has exclusive access to the data stored within. This process ensures the integrity of the data within the data store. Note that several factors can affect exclusive access locking in practice.

Each messaging engine establishes an exclusive lock on its data store. While the messaging engine is running, it maintains that lock to ensure the integrity of the data within the data store.

The data store lock uses database locks and so is an intrinsic part of the data store itself. The relational database management system (RDBMS) relies on the JDBC infrastructure or underlying TCP/IP protocol to indicate the failure of a messaging engine or application server. The RDBMS can then automatically release the data store locks in the database.

The frequency of the liveness checking of the network connection between a messaging engine and the database server for its data store is an important factor in enabling prompt failover of a messaging engine running in a cluster. When messaging engines running in a cluster are configured to fail over between servers, we might have to reduce the TCP/IP keep-alive parameters on the database server to minimize the amount of time before the failure of a messaging engine can be detected.

The SIBOWNER table in the data store holds the lock as a pair of unique identifiers in a single row. When it starts, a messaging engine uses these two identifiers to acquire and maintain its exclusive lock:

MEUUID

The unique identifier for a messaging engine, which remains the same whenever the messaging engine stops and restarts.

INCUUID

The incarnation identifier for a messaging engine, which changes every time the messaging engine starts.

These identifiers determine which messaging engine is using a data store. These identifiers also determine whether a running instance of a messaging engine has maintained its exclusive lock for the time period during which it was running.

The other table used in the data store locking process is the SIBOWNERO table. This table is used for locking only and stores no data in its one EMPTY_COLUMN column.

As a messaging engine starts, it first obtains an exclusive table lock on the SIBOWNERO table. The messaging engine then obtains an exclusive table lock on the SIBOWNER table and proceeds to check the contents. The messaging engine expects to find a single row of data in the table, or no data. If there is an existing row, the messaging engine starts only if the MEUUID that it finds matches its own unique identifier. If the MEUUID does not match, the messaging engine writes error message CWSIS1535 to the server error log and the messaging engine fails to start.

If there are no rows in the SIBOWNER table, the messaging engine inserts one row containing its own MEUUID and INCUUID. If there is a single row in the table and the MEUUID matches the unique identifier for the messaging engine, the messaging engine updates the INCUUID with its own incarnation identifier and attempts to obtain a new shared table lock on the SIBOWNER table. The messaging engine checks again that the INCUUID still matches its own incarnation identifier, in case another instance of the same messaging engine on another server is starting at the same time. If the INCUUID in the table does not match, the messaging engine fails to start.

The shared table lock on the SIBOWNER table remains until the messaging engine stops, with periodic refreshes to ensure that the lock is still in force. The exclusive table lock on the SIBOWNERO table is then released. If the messaging engine cannot refresh the lock on the SIBOWNER table, or discovers from the data in the SIBOWNER table that another messaging engine incarnation is using the data store, the messaging engine writes messages CWSIS1594 and CWSIS1519 to the server error log and the messaging engine stops immediately.

In some cases, when the messaging engine is configured to run in a cluster, if the messaging engine cannot obtain the lock, it stops and is prevented from failing over to another server in the cluster. In these cases check the error logs, because the stopping of the messaging engine has signalled that it is unsafe or impossible to start using the current data store configuration. For descriptions of the situations in which failures might occur and the possible solutions that we can examine, see Diagnosing problems with data store exclusive access locks.

Related tasks

Diagnosing problems with data store exclusive access locks

Tune the detection of database connection loss

Data store tables