Locktimeout INFO messages in the DB2 event logs.

Body

You may sometimes see statements in DB2 event logs such as:  
The current unit of work was involved in an unresolved contention for use of an object
The type of the event is: "Lock timeout".
 
These messages are thrown in less than 30 seconds frequency, even though you have set the Database LOCKTIMEOUT parameter as 30 seconds. You may also see the SQL statement causing the locktimeout:
 
SELECT     YFS_OBJECT_LOCK.* FROM YFS_OBJECT_LOCK YFS_OBJECT_LOCK        
WHERE  (  ( YFS_OBJECT_LOCK.LOCKED_OBJECT_TYPE =  ?   )  AND (           
YFS_OBJECT_LOCK.LOCKED_OBJECT =  ?   )  AND (                            
YFS_OBJECT_LOCK.LOCKED_PARAMETERS =  ?   )  )  FOR UPDATE   
 
YFS_OBJECT_LOCK table is a part of our Sterling Application. The locking mechanism implemented by Sterling uses this table.
 
While you may see several such messages on the event log, you may not see any obvious issue with the working of the application. There is no reason to be alarmed as this is just a part of the mechanism with which our agents operate.
 
When an Agent is triggered (manually through triggeragent.sh or automatically) a getJobs (trigger) message is posted to JMS queue. Within getJobs() method, agent tries to acquire lock on YFS_OBJECT_LOCK table for that specific agent Criteria ID. If the lock is not available then getJobs() method exits and does nothing. If the lock is available then getJobs() method fetches records which needs to be processed.
        
More on YFS_OBJECT_LOCK table:                                                   
                                                                        
This table is used to synchronize the getJobs method call for time triggered transactions, agents, and the trigger agents. This entity contains a record for the criteria being locked. Each of the time triggered transaction java classes have a getJobs method that obtains a lock on the corresponding record in this table before starting on getJobs. This entity has been designed for use in other scenarios too.   
                                                                       
The lock on this table is in NOWAIT mode. In NOWAIT mode if another thread tries to lock an already locked record, it does not wait for the owner thread to release the lock, but stops trying and fails to obtain lock on that record. This is not an error, it is a part of the design.                           
                                                                       
In a multi-threaded environment, when an agent is triggered to process messages for Sterling, all threads awake and try to take a lock on the agent criteria in YFS_OBJECT_LOCK. The first thread to get the lock wins and starts looking for work, which it then posts to a JMS queue. The other threads don't wait for a lock on YFS_OBJECT_LOCK, but they will start processing work messages from the work queue which the first thread has placed there. In this way, one thread gets the jobs, and all threads process jobs. This is done for data integrity and synchronization, with that synchronization taking place at the DB.                                  
                                                                       
A number of short lock timeouts can be expected to be seen in the DB2 logs for this table. The exact number may depend on how many servers/agents/threads are setup. You can use the System management console to examine statistics from the YFS_STATISTICS_DETAILS table to check whether all agents are working as quickly as expected. This behaviour is Sterling application caused, and not controlled by DB2 settings. The default value for LOCKTIMEOUT can be overridden at application level (for any application ).