FAQ – Advanced Authentication Service/DB Hung State: Functional Behavior

Products

• CA Strong Authentication
• CA Advanced Authentication
• CA Advanced Authentication - Risk Authentication (RiskMinder / RiskFort)
• CA Advanced Authentication - Strong Authentication (AuthMinder / WebFort)

Issue/Introduction

This FAQ article focuses on the functional behavior when the Advanced Authentication (AA) service or database is in a hung state, to provide better understanding of the following scenarios:

1. Behavior when Advanced Authentication services are hung.

2. Behavior during a database connection pool issue.

3. Error "ArDBConnection::connect: Connection to database [TESTDSN]. user [TEST] failed"

Environment

Symantec Advanced Authentication 9.1.5.1

Resolution

1. Behavior when Advanced Authentication services are hung.
   

   Q: In the event the application services are hung or unresponsive, will OTP requests still reach the AA application?
   A: Yes, if the service is hung but still accepting connections, requests can reach AA. If the service is completely unresponsive (not accepting connections), requests will fail at the network/load balancer level before reaching AA.

   Q: If yes, what type of errors (if any) would be reported back to the requesting system or customer?
   A: Transaction timeout (Response Code: 5702) — SERVER_TRANSACTION_TIMEOUT. Connection failures — generic connection errors. All the errors are logged in AA logs with transaction IDs.

   Q: If no, how are OTP request failures logged or displayed within AA?
   A: Logged with transaction IDs, error codes, and reason codes. Errors like SERVER_TRANSACTION_TIMEOUT are logged at INFO level. Failures are visible in AA application logs

   
   
2. When There Is a Database Pool Issue
   

   Q: In the event of a database connection pool problem (e.g., exhausted or unavailable pool), how does AA handle incoming OTP requests?
   A: Requests reach the AA layer. If the pool is exhausted, AA waits up to MaxWaitTimeForConnection (default: 30000ms) for a connection.If no connection is available after retries, it attempts failover to the backup database.

   Q: Will OTP requests still hit the AA layer or be rejected before reaching it?
   A: No. Requests reach AA, but processing may fail if no database connection is available.

   Q: What error codes or logs would typically be generated in this scenario?
   A: 1. "All database pools are inactive" — when both primary and backup pools are down. 
       2. "Tried unsuccessfully [N] times to get a connection" — after retry attempts. 
       3. "No active datasource found. DataSources are exhausted" — when all data sources fail. 
       4. Connection errors are logged with error codes and SQL states
   
   

3. Error "ArDBConnection::connect: Connection to database [TESTDSN]. user [TEST] failed"
   
   Q: When this error occurs and what is the criteria for this message. Does this occur every time the AA is not able to connect to DB or will it wait for some moments before it connects to backup DB?
        We don’t see any message that primary DB is down ,so why it is connecting to backup DB again
        MONITOR - ArDBConnection::connect: Connection to database [TESTDSN]. user [TEST] failed. Error detail [SQL State:08001, Native Code: FFFFFFFF, ODBC code: [CA AA][ODBC Oracle Wire Protocol driver][Oracle]TNS-12514: TNS:listener could not resolve  SERVICE_NAME given in connect descriptor SQL State:08001, Native Code: 0, ODBC code: [CA AA][ODBC Oracle Wire Protocol driver]1271]
   
   A: 1. The error message appears when:

            - The backup pool is marked as "bad" (not alive)
            - The monitoring thread (updatePoolStatus) attempts to recover the backup pool
            - The recovery attempt fails with a connection error

       2. Criteria for the message:

            - The backup pool is marked as bad (isAlive() == false)
            - The monitoring thread runs periodically (based on MonitorSleepTime configuration)
            - The recovery attempt (recoverPool) is triggered for the backup pool
            - The connection attempt fails with TNS-12514

       3. Does it wait before connecting to backup DB?

            - Yes. The monitoring thread sleeps between recovery attempts:
            - Normal sleep: MonitorSleepTime (default: 50 seconds from config, but can be configured)
            - If any pool is bad: MonitorSleepTimeOnFailureSecs (if configured) or the normal sleep time
            - The log shows: "Monitor will sleep for [10] because at least one of the pool is marked bad" — this is 10 seconds

        4. Why don't we see a "primary DB is down" message?

            - The monitoring thread attempts to recover both primary and backup pools in each cycle.
            - If the primary pool is already marked as bad and the backup pool is also bad, you may see recovery attempts for the backup pool without an explicit "primary DB is down" message.
            - The primary pool may have been marked bad earlier, and the current cycle is attempting to recover the backup pool.
   
        5. The monitoring logic:

            - Checks both primary and backup pools in each cycle
            - Attempts to recover any pool marked as bad
            - If recovery succeeds, the pool is marked alive
            - If recovery fails, the pool remains marked as bad and the cycle continues