Zde je tok událostí pro ilustraci toho, co se děje:
- Volající požaduje a používá připojení (aplikace nebo fond připojení)
- Volající si ponechá odkaz, aby bylo možné spojení znovu použít
- Volající prochází obdobím nečinnosti (například vývojářský systém přes noc nebo systém kontroly kvality o víkendu).
- Jakmile se toto připojení k databázi nepoužívá, databáze považuje připojení za nečinné. Protože je nečinná, po určité době (výchozí nastavení MySQL je 8 hodin) databáze uzavře spojení.
- Volající má stále k dispozici kliku na spojení, a když se volající pokusí znovu použít spojení, nepříjemně zjistí, že spojení bylo ukončeno.
Důvod, proč autoReconnect=true funguje a že fond testující platnost připojení funguje, je ten, že dáváte volajícímu systému pokyn, aby otestoval připojení pro tuto situaci a aby to zkusil znovu, pokud tato situace nastane.
Pokud jde o to, zda ověřovací dotaz ovlivní výkon:Teoreticky se používá připojení k něčemu. V praxi je něco tak triviální, že jeho účinek je v kontextu celého vašeho systému zanedbatelný.
[EDITACE]
V tomto případě je Apache DBCP fond připojení visící na připojení, ale NECHCETE, aby DBCP ukončilo připojení po každém volání. Smyslem fondu připojení je udržovat připojení připravené pro další hovor, protože vytváření připojení je nákladné. Objekty připojení udržované fondem jsou podporovány skutečnými databázovými připojeními a databáze je ta, kdo toto skutečné připojení po uplynutí časového limitu nečinnosti uzavře. Všimněte si, že časový limit pro uzavření nečinných připojení je nakonfigurován v databázi, nikoli ve fondu připojení. Z tohoto důvodu nemá DBCP žádný způsob, jak zjistit, zda bylo připojení uzavřeno nebo ne, pokud se k němu ve skutečnosti nepokusí připojit. Proto potřebujete ověřovací dotaz.
Další informace o konfiguraci DBCP naleznete na stránce konfigurace a dokumenty API .