Det underliggende problem endte med at være ufrigivne databaseforbindelser. Når en forbindelse åbnes, bliver den tjekket ud af forbindelsespuljen. Hvis forbindelsen aldrig lukkes, tror poolen, at den stadig bliver brugt. Dette får poolstyringslogikken til med jævne mellemrum at godkende igen med databasen ved hjælp af den originale forbindelsesstreng. Når adgangskoden ændres, fører dette hurtigt til mislykkede loginforsøg og kontolåsning.
// 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.
}
Den korrekte løsning på dette problem er at sikre, at forbindelser altid returneres til poolen, når du er færdig med dem!
// 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.
}
BEMÆRK:Andre svar foreslog at slå pooling fra og rydde gamle forbindelsespuljer, når adgangskoden blev ændret. Disse forslag fungerede for os som en midlertidig patch, mens vi søgte efter de ikke-frigivne ressourcer, og de hjalp os i høj grad med at isolere problemet.