QZDASOINIT unterscheiden

[RobertPic]

Zum Unterscheiden:

Die Jobs QZDASOINIT halten eine Sperre auf den Anmeldebenutzer.

ein WRKOBJLCK JAVAUSR OBJTYPE(*USRPRF)

zeigt z.B. alle Jobs, welche den Benutzer JAVAUSR verwenden, auch QZDASOINIT.
Leider hat WRKOBJLCK keine FileOutput.

Auch für die Sperren vom Job kommt man an das benutzte Userprofil (dort gibt es ein Outfile).

Zum 2. Problem:
Da ist die Java-Anwendung unsauber programmiert. Ich tippe auf PrepearedStatements die bei jeder Benutzung neu gemacht werden. Entweder schließt man sie nach der Benutzung oder besser man macht sie nur einmal auf.

Der Code könnte in etwas so aussehen:

public boolean fetchByFirKunr(int firma, int kundennr) {
        try {
            if (fetch == null) {
                fetch = as400Conn.getConn().prepareStatement(
                 "Select " + fieldList + " from mixdta.mkun where " +
                 "mkufir = ? and mkukunr = ?");
            }
            fetch.setInt(1, firma);
            fetch.setInt(2, kundennr);

            retRs = fetch.executeQuery();
            geladen = retRs.next();
            if (geladen) {
                this.mapping(retRs);
            }
             ..... 

Laut Lehrbüchern sollte man sowieso ResultSet und Statement schließen und die Connection einem Connectionpool zurückgeben. Aber ich halte mir für einfache Serverjobs und kleine GUI-Awendungen lieber eine Connection offen.

Robert P.

[Christian.Hesse]

Hallo RobertPic,

du hast recht: Es waren PreparedStatements, die nicht geschlossen sind. Vielen herzlichen Dank.

Die Rückgabe der Verbindungen an einen Connection Pool wird derzeit nur beim Application Server genutzt, da die "Clients", die mir momentan mit das größte Kopfzerbrechen bereiten 24/7 connected sind und SQL-Statements ausführen. Diese bestehen aus einer Verbindung von einer Java-Anwendung, die alleine auf einem Rechner untergebracht ist, weswegen ich den Nutzen eines Connection Pools in diesem Fall nicht sehe.

Da fällt mir aber noch etwas anderes ein: In den Applikationen wird zum Schreiben in die Datenbank ein RPG-Programm mit Parametern aufgerufen, welches das Schreiben übernimmt. Angeblich soll das bei der Implementierung deutlich schneller gewesen sein als die Nutzung von Insert/Update per JDBC. Hat da jemand Erfahrungen dazu?

Ich werde mal versuchen, meinen Problemen weiter auf den Grund zu gehen - vielleicht findet sich noch irgendetwas, was ich bisher übersehen habe.

In diesem Sinne nocheinmal herzlichen Dank allen und bis bald!

Gruß

Christian

[RobertPic]

.... Es waren PreparedStatements, die nicht geschlossen sind.

Rein vom Speed her, würde ich sie weiterhin offen lassen. Also für die gesamte Klasse deklarieren, aber das Statement nur erzeugen wenn es null ist (Beispielcode) oder dafür einen Schalter machen.

Nachteil: Dateien bleiben geöffnet (aktiver Job bei Sicherungen)
Vorteil: schnellste Lösung

....weswegen ich den Nutzen eines Connection Pools in diesem Fall nicht sehe.

Sehe ich genauso. Einen ConnectionPool brauche ich erst, wenn ICH die Übersicht verliere (WebServer, komplexe GUI und/oder Multithread-Applikationen)...

... In den Applikationen wird zum Schreiben in die Datenbank ein RPG-Programm mit Parametern aufgerufen, welches das Schreiben übernimmt. Angeblich soll das bei der Implementierung deutlich schneller gewesen sein als die Nutzung von Insert/Update per JDBC. Hat da jemand Erfahrungen dazu?

Also unter normalen Umständen, kann ich mir das eigentlich nicht vorstellen. Vielleicht wenn ein Aufruf viele DB-Operationen erzeugt.

Auch bei Updates habe ich, von der Performance her, mit offen gelassenen PreparedStatements gute Erfahrungen gemacht.

Eventuell hilft dieser Thread
bei der Performancesuche etwas.

Bei DB-Updates macht nichtmal unsere kleine Entwicklungsmaschine (170er) mucken.

Robert P.

[BenderD]

Hallo,

das mit dem Connection Pool...
Hauptvorteile sind:
- einfacheres Transaktionshandling (pro Transaktion eigene Connection vom Pool)
- Zentralisierung des Connection Handlings (ab und an schließen und neue öffen, wg. vergammeln etc.)
- gute Pools können prepared Statements cross Connection poolen
Primär geht es um Design und erst sekundär um Performance!!!

Zur Performance von updates: bei read Write Logik ist es meist vorteilhaft positioned updates über ResultSet zu machen statt searched updates

Ansonsten geht im allgemeinen messen (DBMON) über raten.

mfg

Dieter Bender

Hallo RobertPic,

du hast recht: Es waren PreparedStatements, die nicht geschlossen sind. Vielen herzlichen Dank.

Die Rückgabe der Verbindungen an einen Connection Pool wird derzeit nur beim Application Server genutzt, da die "Clients", die mir momentan mit das größte Kopfzerbrechen bereiten 24/7 connected sind und SQL-Statements ausführen. Diese bestehen aus einer Verbindung von einer Java-Anwendung, die alleine auf einem Rechner untergebracht ist, weswegen ich den Nutzen eines Connection Pools in diesem Fall nicht sehe.

Da fällt mir aber noch etwas anderes ein: In den Applikationen wird zum Schreiben in die Datenbank ein RPG-Programm mit Parametern aufgerufen, welches das Schreiben übernimmt. Angeblich soll das bei der Implementierung deutlich schneller gewesen sein als die Nutzung von Insert/Update per JDBC. Hat da jemand Erfahrungen dazu?

Ich werde mal versuchen, meinen Problemen weiter auf den Grund zu gehen - vielleicht findet sich noch irgendetwas, was ich bisher übersehen habe.

In diesem Sinne nocheinmal herzlichen Dank allen und bis bald!

Gruß

Christian