Podstawowym problemem okazały się niewydane połączenia z bazą danych. Gdy połączenie zostanie otwarte, zostanie wyewidencjonowane z puli połączeń. Jeśli połączenie nigdy nie zostanie zamknięte, pula myśli, że jest nadal używana. Powoduje to okresowe ponowne uwierzytelnianie logiki zarządzania pulą w bazie danych przy użyciu oryginalnych parametrów połączenia. Zmiana hasła szybko prowadzi do nieudanych prób logowania i zablokowania konta.
// Problem logic; connection is never closed/returned to the connection pool.
public static void ConnPoolTest1()
{
OracleConnection conn = new OracleConnection(connectionStringWithPooling);
conn.Open();
//...Do some work
// Sit on this line for 5-10 minutes and examine Oracle's dba_audit_trail.
Console.ReadKey(); // Since connection was never released back to the connection pool, the
// data provider's pool management will regularly re-authenticate with DB.
// If user's password changes before this process dies (releasing the
// connection pools), you start accumulating failed password attempts.
}
Właściwym rozwiązaniem tego problemu jest upewnienie się, że połączenia są zawsze zwracane do puli po ich zakończeniu!
// Best practice: ALWAYS CLOSE YOUR CONNECTIONS WHEN YOU ARE DONE!
public static void ConnPoolTest2()
{
OracleConnection conn = new OracleConnection(connectionStringWithPooling);
conn.Open();
//...Do some work
conn.Close();
// Sit on this line for 5-10 minutes and examine Oracle's dba_audit_trail.
Console.ReadKey(); // No problem here! No recurring authentication attempts because the
// connection has been returned to the pool.
}
UWAGA:Inne odpowiedzi sugerowały wyłączenie poolingu i wyczyszczenie starych pul połączeń po zmianie hasła. Te sugestie działały dla nas jako tymczasowa łatka, gdy szukaliśmy niewydanych zasobów, i bardzo pomogły nam w wyizolowaniu problemu.
