In JDBC is de setFetchSize(int) methode is erg belangrijk voor de prestaties en het geheugenbeheer binnen de JVM, omdat deze het aantal netwerkaanroepen van de JVM naar de database regelt en dienovereenkomstig de hoeveelheid RAM die wordt gebruikt voor ResultSet-verwerking.
Als setFetchSize(10) wordt aangeroepen en het stuurprogramma negeert het, zijn er inherent waarschijnlijk maar twee opties:
- Probeer een ander JDBC-stuurprogramma dat de hint van ophaalgrootte respecteert.
- Bekijk stuurprogramma-specifieke eigenschappen op de verbinding (URL en/of eigenschappenkaart bij het maken van de verbindingsinstantie).
De RESULT-SET is het aantal rijen dat op de DB is opgesteld als reactie op de query. De ROW-SET is het stuk rijen dat uit de RESULT-SET wordt gehaald per aanroep van de JVM naar de DB. Het aantal hiervan oproepen en het resulterende RAM-geheugen dat nodig is voor verwerking, is afhankelijk van de instelling voor de ophaalgrootte.
Dus als de RESULT-SET 100 rijen heeft en de ophaalgrootte 10 is, zullen er 10 netwerkaanroepen zijn om alle gegevens op te halen, waarbij op elk moment ongeveer 10*{row-content-size} RAM wordt gebruikt.
De standaard fetch-grootte is 10, wat nogal klein is. In het geval dat het wordt gepost, lijkt het erop dat de bestuurder de instelling voor de fetch-size negeert en alle gegevens in één oproep ophaalt (grote RAM-vereiste, optimale minimale netwerkoproepen).
Wat gebeurt er onder ResultSet.next() is dat het niet één rij per keer uit de RESULT-SET haalt. Het haalt dat op van de (lokale) ROW-SET en haalt de volgende ROW-SET (onzichtbaar) op van de server als deze uitgeput raakt op de lokale client.
Dit hangt allemaal af van het stuurprogramma, aangezien de instelling slechts een 'hint' is, maar in de praktijk heb ik ontdekt dat het voor veel stuurprogramma's en databases zo werkt (geverifieerd in veel versies van Oracle, DB2 en MySQL).