c3p0 maxIdleTime är samma som wait_timeout för mysql?

Först Låt oss förstå mysql-egenskaperna.

• interactive_timeout :interaktiv timeout för mysql-skalsessioner i sekunder som mysqldump eller mysql kommandoradsverktyg. anslutningarna är i viloläge. För det mesta är detta inställt på ett högre värde eftersom du inte vill att det ska kopplas från medan du gör något på mysql cli.
• wait_timeout :antalet sekunder under inaktivitet som MySQL väntar innan det stänger en anslutning på en icke-interaktiv anslutning på några sekunder. exempel:ansluten från java. anslutningar är i viloläge.

Låt oss nu förstå c3po-egenskaper och dess relation med DB-rekvisita.(Jag ska bara kopiera från din fråga)

Detta syftar på hur länge ett anslutningsobjekt kan vara användbart och kommer att finnas tillgängligt i poolen. När timeouten är över kommer c3po att förstöra den eller återvinna den.

Nu kommer problemet när du har maxIdleTime högre än wait_timeout .låt oss säga om mxIdleTime : 50 sekunder och wait_timeout : 40 s då finns det en chans att du får Connection time out exception: Broken Pipe om du försöker göra någon operation under de senaste 10 sekunderna. Alltså maxIdelTime bör alltid vara mindre än wait_timeout .

Istället för maxIdleTime kan du använda följande egenskaper.

• idleConnectionTestPeriod sätter en gräns för hur länge en anslutning kommer att vara inaktiv innan den testas. Utan preferredTestQuery , standardvärdet är DatabaseMetaData.getTables() - som är databasagnostisk, och även om det är ett relativt dyrt samtal, är förmodligen bra för en relativt liten databas. Om du är paranoid när det gäller prestanda, använd en fråga som är specifik för din databas (i.e. preferredTestQuery="SELECT 1")
• maxIdleTimeExcessConnections kommer att återföra anslutningenCount backdown till minPoolSize efter en ökning av aktiviteten.

Observera att någon av poolegenskaperna (t.ex. maxIdleTime ) påverkar endast anslutningar som finns i poolen d.v.s. om hibernate har skaffat en anslutning och håller den inaktiv i mer än maxIdleTime och sedan försöker göra valfri operation kommer du att få "Broken Pipe"

Det är bra att ha lägre wait_timeout på mysql men det är inte alltid rätt när du redan har ett program byggt. Du måste se till innan du minskar det att du inte håller anslutningen öppen för mer än wait_time ut.

Du måste också tänka på att det är dyrt att skaffa en anslutning och om väntetiden är för kort så slår det hela syftet med att ha anslutningspool, eftersom det ofta försöker skaffa anslutningar.

Detta är särskilt viktigt när du inte gör anslutningshantering manuellt, till exempel när du använder Spring transnationella API. Våren startar transaktionen när du anger en @Transaction annoterad metod så att den får en anslutning från poolen. Om du ringer något webbtjänstsamtal eller läser någon fil som tar längre tid än wait_time out så får du undantag.

Jag har stött på det här problemet en gång.

I ett av mina projekt hade jag en cron som skulle göra orderhantering åt kunder. För att göra det snabbare använde jag batchbearbetning. Nu när jag hämtar ett parti kunder och gör lite bearbetning (inga db-anrop). När jag försöker spara alla beställningar jag brukade få trasigt rör undantag. Problemet var att min wait_timeout var 1 minut och beställningshanteringen tog längre tid än så. Så vi var tvungna att öka den till 2 minuter. Jag kunde ha minskat batchstorleken men det gjorde den totala bearbetningen långsammare.