SQL7049 nach häufigem Aufruf einer Stored Procedure

[KM]

Hallo zusammen,

ich habe folgendes Problem. Ich habe eine Stored Procedure in RPG mit Embedded SQL, bei der ein Resultset mit "SET RESULT SETS..." zurückgegeben wird. Diese SP wird in einem Java-Programm häufig aufgerufen. Irgendwann erhalte ich dann den Fehler SQL7049. Hier ist eine Beschreibung dazu:

https://www.ibm.com/support/pages/ca...essage-sql7049

Das ist genau das Phänomen, das ich auch habe. Anscheinend wird das Resultset in der SP nicht geschlossen. Nur wie und an welcher Stelle kann ich das denn schließen? Im RPG-Programm kann und darf ich es ja noch nicht schließen, da das Resultset ja erst mal an Java übergeben werden muss. Und in Java mache ich ja einen Close auf das Resultset, das CallableStatement und die Connection. Hier noch ein Ausschnitt aus dem Java-Programm:

try {
            CallableStatement cs = conn.prepareCall("{call internet.int101(?,?,?,?,?,?,?,?)}");
            cs.setInt(1, firma);
            cs.setInt(2, kundennummer);
            cs.setString(3, sprachcode);
            cs.setInt(4, selektionstyp);
            cs.setInt(5, produktgruppe);
            cs.setString(6, anwendungsbezeichnung);
            cs.setInt(7, navigation);
            cs.setString(8, artikelnummer);
            ResultSet rs = cs.executeQuery();
            while (rs.next()) {
            	// nächste Artikeldaten
                ...
            }
         }
		catch (Exception e) {
		}
		finally {
			try {
				if (rs != null) {
					rs.close();
					rs = null;
					} 
			} catch (SQLException e) {}
			try {
				if (cs != null) {
					cs.close();
					cs = null;
					} 
			} catch (SQLException e) {}
			try {
				if (conn != null) {
					conn.close();
					conn = null;
					} 
			} catch (SQLException e) {}
        }

Die Connections werden aus einem Connection Pool geholt.

Wo liegt hier das Problem und wie kann ich es lösen?

Vielen Dank!
KM

[Fuerchau]

Das Problem ist tatsächlich, dass du an den eigentlichen Close des Cursors via ODBC/JDBC so nicht drankommst.
Allerdings, wenn du unter Transaktionen (commit=*CHG) arbeitest, wird beim Commit/Rollback auch ein Cursor geschlossen, der nicht mit HOLD definiert wurde.
Commit ist allerdings nur möglich, wenn du das bei der Connection bereits angibst und BeginTransaction verwendest. Problematisch ist es dann, wenn die zu verarbeitenden Dateien ggf. nicht aufgezeichnet werden.

Als Alterative kann die Procedure auch eine Global temporary Table erstellen (liegt dann in QTEMP), die du dann mt einem 2. SQL ausliest.

[KM]

Danke schon mal für Deine Antwort!

Commitment Control wird hier nicht gemacht. Das scheidet also schon mal aus.

Und bei der zweiten Lösung meinst Du, dass eine Global Temporary Table anstatt eines Resultsets erstellt werden soll? Das würde sicher auch Konflikte mit sich bringen, da das Java-Programm über den Connection-Pool viele Aufrufe im selben Job macht. Ob dann immer auf die richtige Table zugegriffen wird? Das scheint mir ein zu großer Wackelhaufen zu sein. Außerdem würde das ca. 50 Stored Procedures betreffen. Die müsste ich alle umbauen. Das geht nicht.

Vielleicht fällt mir ja noch was anderes ein. Auf dieses Limit von 256 offenen Resultsets bin ich bisher auch nie gestoßen. Das macht aus meiner Sicht auch überhaupt keinen Sinn. Warum wird dieses Resultset nicht einfach am Ende der Stored Procedure automatisch gelöscht? Vor allem wenn man danach von außen nicht mehr darauf zugreifen kann.

Würde man evtl. mit "ASSOCIATE RESULT SET LOCATORS...WITH PROCEDURE..." und "ALLOCATE...CURSOR FOR RESULT SET..." weiterkommen? Dann könnte man einen "CLOSE" auf den Cursor machen.

Viele Grüße,
KM

[Fuerchau]

Ich sagte ja, der JDBC-Treiber selber hat das Resultset und kennt den Cursornamen.
Und mit dem Pool hat das auch nichts zu tun, da dieser nicht prozessübergreifend arbeitet sondern nur innerhalb deines Prozesses wirkt.

Ob das mit dem Associate klappt, kann ich nicht sagen, denn es ist nicht dokumentiert ist, dass der Cursor geschlossen wird, wenn der Drop Locator ausgeführt wird.

Ich nehme mal an, dass diese Prozeduren nur lesend auf Daten zugreifen und den Cursor zurück liefern. Dann wäre es doch ein leichtes, mal in der Verbindung mit Commit zu arbeiten um nach dem Ende einfach einen Commit ausführen zu können.
Journalisierung wird nur bei Insert/Update/Delete benötigt. Sollten die Prozeduren noch Daten protokollieren oder sonstige Updates machen, so kann man diese Aktion mit "with NC" beenden (with No Commit), so dass kein Journal benötigt wird.

Ob das funktioniert kannst du ja im Joblog des QZDASOINIT-Jobs sehen.

By the way: SQL-Anwendungen ohne Jounalisierung und Transaktionen sind sowieso grenzwertig;-).