Diagnosing problems with data store exclusive access locks

Diagnose problems with data store exclusive access locks

Diagnose the causes of problems with data store exclusive access locks and examine possible causes to the problems.

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.

Compare your symptoms with those listed in the following table and examine the possible solutions:

Symptom Cause Solution
The messaging engine cannot start nor failover to another server. The messaging engine writes error message CWSIS1519 The messaging engine cannot connect to the database specified in the data source that we configured to enable the messaging engine to access its data store.

Check that connectivity to the database is possible when using the defined data source.
If we can connect to the database, another instance of the messaging engine might hold a lock on the data store. Check for other running instances of the messaging engine.
If the messaging engine is taking over from another that was running on a different server in the same cluster, the database might not have released the database locks that comprise the data store lock. Use the administration tools for our relational database management system to examine the locks on the SIBOWNER table. If the database is still holding locks after the failure of a server, ensure that we configure the liveness checking of the network connection between the application server and the database server appropriately. For example, examine the TCP keep alive parameter.
(ZOS) If we are using DB2 for z/OS, we can examine the DB2 Idle Thread Timeout.

After a delay of many minutes, the messaging engine cannot failover to another server and writes error message CWSIS1519. Another instance of the same messaging engine is holding the data store lock, or the database has not released a data store lock that was held by a failed instance of the same messaging engine.

If we can connect to the database, another instance of the messaging engine might hold a lock on the data store. Check for other running instances of the same messaging engine. Only one instance of each messaging engine can run in a cluster at a given time.
After the failure of an instance of a messaging engine or an application server running in a cluster, the database might not have released the database locks that comprise the data store lock. Use the administration tools for our relational database management system to examine the locks on the SIBOWNER table. If the database is still holding locks after the failure of a server, ensure that we configure the liveness checking of the network connection between the application server and the database server to enable prompt failover. For example, examine the TCP keep alive parameter.
(ZOS) If we are using DB2 for z/OS, we can examine the DB2 Idle Thread Timeout.

We might have to use the database administration tools to force the release of the lock on the data store.

The messaging engine fails to start and writes error messages CWSIS1535 and CWSIS1519 The identifiers in the SIBOWNER table do not match those of the messaging engine.

Check that the data source that we configured for the messaging engine refers to the correct database.
If the MEUUID identifiers do not match, check that a previous messaging engine did not use the same tables. If the tables already exist, DROP the tables and CREATE them again for the new messaging engine.
If the INCUUID identifiers do not match, another instance of the same messaging engine is running and has acquired the lock. Check for other running instances of the messaging engine.

The messaging engine starts but then stops and writes error message CWSIS1519. The messaging engine has lost its lock on the data store.

Check that we have connectivity to the database through the data source specified. The messaging engine might have lost network connectivity and be unable to maintain a connection with the database.
If we can connect to the database, another instance of the messaging engine might have started and obtained a lock on the data store. Check for other running instances of the messaging engine.

Related:

Data store exclusive access
Tune the detection of database connection loss
Troubleshoot service integration technologies

Symptom	Cause	Solution
The messaging engine cannot start nor failover to another server. The messaging engine writes error message CWSIS1519	The messaging engine cannot connect to the database specified in the data source that we configured to enable the messaging engine to access its data store.	Check that connectivity to the database is possible when using the defined data source. If we can connect to the database, another instance of the messaging engine might hold a lock on the data store. Check for other running instances of the messaging engine. If the messaging engine is taking over from another that was running on a different server in the same cluster, the database might not have released the database locks that comprise the data store lock. Use the administration tools for our relational database management system to examine the locks on the SIBOWNER table. If the database is still holding locks after the failure of a server, ensure that we configure the liveness checking of the network connection between the application server and the database server appropriately. For example, examine the TCP keep alive parameter. (ZOS) If we are using DB2 for z/OS, we can examine the DB2 Idle Thread Timeout.
After a delay of many minutes, the messaging engine cannot failover to another server and writes error message CWSIS1519.	Another instance of the same messaging engine is holding the data store lock, or the database has not released a data store lock that was held by a failed instance of the same messaging engine.	If we can connect to the database, another instance of the messaging engine might hold a lock on the data store. Check for other running instances of the same messaging engine. Only one instance of each messaging engine can run in a cluster at a given time. After the failure of an instance of a messaging engine or an application server running in a cluster, the database might not have released the database locks that comprise the data store lock. Use the administration tools for our relational database management system to examine the locks on the SIBOWNER table. If the database is still holding locks after the failure of a server, ensure that we configure the liveness checking of the network connection between the application server and the database server to enable prompt failover. For example, examine the TCP keep alive parameter. (ZOS) If we are using DB2 for z/OS, we can examine the DB2 Idle Thread Timeout. We might have to use the database administration tools to force the release of the lock on the data store.
The messaging engine fails to start and writes error messages CWSIS1535 and CWSIS1519	The identifiers in the SIBOWNER table do not match those of the messaging engine.	Check that the data source that we configured for the messaging engine refers to the correct database. If the MEUUID identifiers do not match, check that a previous messaging engine did not use the same tables. If the tables already exist, DROP the tables and CREATE them again for the new messaging engine. If the INCUUID identifiers do not match, another instance of the same messaging engine is running and has acquired the lock. Check for other running instances of the messaging engine.
The messaging engine starts but then stops and writes error message CWSIS1519.	The messaging engine has lost its lock on the data store.	Check that we have connectivity to the database through the data source specified. The messaging engine might have lost network connectivity and be unable to maintain a connection with the database. If we can connect to the database, another instance of the messaging engine might have started and obtained a lock on the data store. Check for other running instances of the messaging engine.