Miután leírtad, mit akarsz csinálni már tényleg nem értem mi az akadály.
Szerintem: Mivel számolni fogsz az adatokkal úgyis fogsz csinálni egy burkoló osztályt az adatbázis sorainak. Tehát a lépések:
1. Legyen meg, hogy végigolvasod a táblát, de nem tárolod sehova. Ez a setfetchsize vagy mittudoménmi hangolásán múlik, hogy ne foglaljon túl sokat. Ilyet még konkértan nem csináltam adatbázisból eddig mindig kevés már leszűrt adatot kérdeztem le.
2. A rekordokat (másolatot) beolvasáskor tedd bele a burkoló osztályba, így a resultsettől függetlenül a kezedben van az adathalmaz
3. A burkoló ojjektumokat gyűjtsd mondjuk egy ArrayList-be. Ha rendezni is kell, akkor jobb lehet egyből TreeMap-be tenni.
4. mikor megvan az N ojjektum, dolgozd fel, aztán usgyi üríted az ArrayListedet és kezdede elölről.
5. Az ojjektumaid memória használatát tutod monitorozni többféleképpen:
1. Csak 1 féle funkciót aktiválsz a programodban (csak resultset felolvasás, vagy csak ojjektumlista építés), System.gc() és java.lang.maxmemory, freememory, totalmemory hármassal meg lehet tudni, hogy mennyit eszik épp a program. Ezekből következtetni lehet 1 ojjektum méretére, amiből már kiderül, hogy mik a rendszer korlátai
2. vannak Javás memória elemző módszerek is (mindenféle JVM kapcsolókkal szedhetők elő), de ezeket nem javaslom, az első módszer legtöbb esetben elegendő, és kevesebb otánajárást igényel
6. Ha nem fér így sem bele a memóriába, akkor nem lehet megcsinálni. Illetve meg lehet próbálni, hogy nem ojjektummal burkolod, hanem valami tömör módon bájt, int, vagy float tömbbe írod az adatokat, azzal lehet memóriát spórolni (viszonylag sokat). Ha erre az "adatszerkezetre" írsz burkoló osztályt statikus metódusokkal, ami ojjektumszerűen éri el, akkor még szépen is lehet. 1X csináltam ilyet, de inkább csak kísérletképpen.
7. Ha 6 szerint sem fér a memóriába, akkor assemblerben sem fér bele és a feladat lehetetlen kategóriájú.