Siteminder ODBC ConnectionHangWaitTime and ConnectionTimeout clarification
search cancel

Siteminder ODBC ConnectionHangWaitTime and ConnectionTimeout clarification

book

Article ID: 228128

calendar_today

Updated On:

Products

CA Single Sign On Federation (SiteMinder)

Issue/Introduction

Clarification on the usage of ConnectionHangWaitTime  and ConnectionTimeout ODBC registry keys listed below 

 

https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/siteminder/12-8/configuring/policy-server-configuration/configure-policy-server-data-storage-options/configure-odbc-data-store-options.html#concept.dita_b820cc1b2a7b4cb82f945a96ab84285914ae9722_ConfigureODBCRegistrySettingsforTimeout

 

Environment

Release : 12.8.x

Component : SITEMINDER -POLICY SERVER

Resolution

**** ConnectionTimeout -->  

is timeout for a execution of one ODBC statement. For some specific statements  specific timeouts can be specified: LoginTimeout for login, QueryTimeout for search. 
Specific timeout overwrite the generic ConnectionTimeout for that specific operation.
If Timeout happens, the connection status  is set to 'hung', but no action taken to fix the connection right away.
 
Each connection is monitored by a MonitorThread. The monitor periodically checks the status of the connection. If the connection status is 'hung', monitor evaluates if now is the right time to fix the connection. 

For this the monitor calculates time passed from the last activity on the connection. (each activity updates the HeartbeatTimestamp  field of the connection).

The algorithm is:

IF  ( (current_time - HeartbeatTimestamp)  > 2 * ConnectionHangWaitTime) THEN fix the hanged connection, i.e. disconnect and then reconnect.

 

*** ConnectionHangWaitTime -->  

is used only in case the connection monitor thread suspects another thread may be still using the connection. For example, in the case of shared connection, one thread experienced the timeout and marked the connection as 'hung', but another thread is still successfully executing an ODBC search on the same connection. We want to give this thread a chance to finish.

In case  the connection monitor is sure the connection is not  being used right now, it fixes the connection right away without checking if enough time has passed since the last heartbeat timestamp update.