Java JDBC Sperre

[Xanas]

Treiber Bug weis ich nicht, aber ich habe einfach mal das jt400.jar aus der Client Access Installation verwendet statt aus der aktuellen Version des jtopen_7_1 und schon funktioniert das Log auch korrekt. Kann das sein, das jtopen_7_1 für V7R1 vorbehalten ist? Wir haben nämlich nur V6R1 auf unserem Hobel.

... sieht für mich nach einem Treiber Bug aus. Im richtigen Leben sollte man ohnehin log4j in der Applikation nutzen.

D*B

[BenderD]

... jtopen V7.0+ geht rückwärts bis V5R3, für JDBC je nach JDBC Spezifikation. Das Log hat mit dem Server eh nix zu tun, das ist eine reine Treiber Eigenschaft => definitiv Bug!

D*B

Treiber Bug weis ich nicht, aber ich habe einfach mal das jt400.jar aus der Client Access Installation verwendet statt aus der aktuellen Version des jtopen_7_1 und schon funktioniert das Log auch korrekt. Kann das sein, das jtopen_7_1 für V7R1 vorbehalten ist? Wir haben nämlich nur V6R1 auf unserem Hobel.

[fdaiofur]

muss nicht

ps1.close
bzw.
ps2.close

stehen im PHP-Code ?

[Xanas]

ja stimmt, aber die Sperren bleiben trotzdem hängen.

[Fuerchau]

Solange Connection-Pooling eingeschaltet ist, bleiben ODP's, die mehr als 1 mal verwendet wurden, offen bis die Verbindung über den Pool auch tatsächlich geschlossen wird.
ODP's haben mit geöffneten SQL-Cursorn nur indirekt was zu tun.
Beim 1. Open werden sie erstellt und beim 1. Close wieder geschlossen.
Beim 2. Open bleibt dieser bis zum echten Verbindungsclose dann offen.

Ein Close auf einer Connection schiebt diese nur in den Pool zurück, eine tatsächlicher Close erfolgt nicht.
Da hilft nur, ConnectionPooling (mit den entsprechenden Leistungseinbussen bei häufigem Open/Close) abzuschalten.