Så som skrevet i min kommentar til spørgsmålet, er det officielle svar fra MySQL-stikket, at du skal streame hele resultatsættet for at det kan lukke (http://dev.mysql.com/doc/refman/5.5/en/connector-j- reference-implementation-notes.html ). Derudover kan du ikke udføre flere forespørgsler, mens et streamingresultat finder sted.
Som et fuldstændig ulækkert hack brugte jeg refleksion til at gå ned i RowDataDynamic (ver. 5.1.24) og forfalske en afbrudt undtagelse, som sådan:
final Class<?> rdClass = rd.getClass();
final Field isInterruptedField = rdClass.getDeclaredField("isInterrupted");
isInterruptedField.setAccessible(true); // override 'protected' visibility
isInterruptedField.set(rd, true);
Bemærk, du bliver nødt til at gå ned af det objekt, du har styr på, for at komme til resultatsættet. For mig brugte jeg Hibernates ScrollableResults-klasse. Det betød, at man hentede ResultSet-reference fra det (dets superklasse, faktisk), og derefter RowData derfra.
Dette vil tillade lukkeoperationen at finde sted uden at streame resten af resultaterne DOG Jeg får en undtagelse på grund af uoverensstemmende pakkestørrelse, når jeg forsøger at rulle transaktionen tilbage (som jeg bare fanger og ignorerer). Ved at bruge Atomikos som forbindelsespuljen vil jeg se advarsler om de næste par forbindelser, efterhånden som tingene bliver ryddet op, men alt fungerer stadig ok.
Det er klart, at denne tilgang måske ikke virker for alle, men det er i det mindste en løsning, når behandlingen via databaseforespørgslen eller skrive mere kompliceret logik for at hente resultater i batches, bare ikke virker.