WAS v8.5 > WebSphere applications > Service integration > Message stores > Data stores

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 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 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 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.


Related


Diagnose problems with data store exclusive access locks
Tune the detection of database connection loss


Reference:

Data store tables


+

Search Tips   |   Advanced Search