28. oktober 2003 - 15:53Der er
9 kommentarer og 1 løsning
Database-problemer (MySQL) og timeout
Jeg har efterhånden en masse problemer med en server der kører mod en database. Hver klienter kommer ind på serveren indlæses data fra databasen og hver gang klienter forlader serveren, gemmes data.
Problemet er at databasen ofte er ret ustabil. Nogen gange er tabeller af andre delsystemer låst i for længere tid (10-60 sekunder), andre gange er databasen bare overbelastet eller helt nede.
Mit mål er at min server kan køre videre og evt. blot afvise klienter, hvis der er problemer med databasen. Her er problemet så: kan PreparedStatement.executeQuery() afbrydes, hvis det tager for lang tid, kan der sættes timeout på eller er man tvunget til at vente?
Samtidig leder jeg efter en connction-pool, som ikke er for stor og avanceret, men kan finde ud af at håndtere, hvis databasen er helt nede i f.eks. 5 minutter og derefter er tilgængelig igen; nogle links ville være rart.
Andre løsningsforslag, ideer ønskes desuden velkomne. Hvor normalt er det i større systemer, at delsystemerne skal håndtere database-problemer, hvis i forstår? Kan BGBanks systemer f.eks. tåle at alle databaser er utilgængelige i 5 minutter og hvad gør de evt?
Databasen hedder i øvrigt MySQL er er ikke just gearet til den stillede opgave, men alt for mange faktorer gør at et DBMS-skift ikke er muligt. Nogen der ved hvordan MySQL håndterer samtidighed i forbindelse med læsning og skrivning til tabeller?
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Hvis du skal sætte timeout vil jeg formode at du skal sætte en driver specific property i de properties du kan kalde getConnection med.
Prøv at sætte property "timeout" til et antal millisekunder.
Hvis du kan leve med at tabe data hvis applikationen går ned (det kan bankerne ikke), så kan du putte alle database gem requests i en kø og så have en tråd der henter fra den kø og skriver til databasen. Den tråd kan så godt være bagefter så længe der er memory til køen.
Hvis du ikke kan leve med at tabe data ved applikations nedbrud, så er det bedste formentlig bare at stoppe hvis databasen ikke kan følge med.
At implementere noget med at gemme temporært i nogle flat files vil hurtigt blive meget komplekst.
Jeg kan forstå at det at skifte database ikke e en option.
Er en MySQL database mere en mulighed ? I så fald kunne du kigge på c-jdbc produktet !
Jeg kan umiddelbart godt lide ideen med at gem requests lægges i en kø, som en tråd står og tæsker igennem. Mere kompliceret bliver det dog når klienter modtages. Klienten kan ikke komme ind på serveren før denne er logget ind og nogle data er indlæst fra databasen. Så skal der vel laves noget med at indgående klienter queues til deres data kan blive indlæst fra databasen.
Hvis du har en tråd per client så var det nok mest logisk at execute load i den kontekst (den tråd kan jo alligevel ikke noget før data er loadet) og nøjes med at queue save.
Hvis du har få tråde der servicerer mange klienter så kunne du lade queue processoren både loade data og sende til client. SÅ er vo ovre i noget command pattern.
Hvis du vil have nogen point, må du jo lægge et svar... :)
Løsningen blev indtil videre at kompilere MySQL til at udnytte mere end én processer samt slå logging fra (MySQL oplyser at det forøger hastigheden med 3%). Problemet bestod primært i, at MySQL-serveren havde mere end 400 statements at se til i sekundet, men nu hvor den udnytter alle processorerne, ser det lidt pænere ud :)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
